Stephen Frost <sfrost@xxxxxxxxxxx> writes: > * Tom Lane (tgl@xxxxxxxxxxxxx) wrote: >> This is the standard mistake about pg_dump, which is to imagine that it >> depends only on userspace operations while inspecting schema info. It >> doesn't; it makes use of things like ruleutils.c which operate on "latest >> available data" rules. > There's two different points here- the first is the whole discussion > around why pg_dump is depending on the backend for bits and pieces but > not everything, but the second is- aren't the accesses from ruleutils.c > now using an MVCC snapshot? Yeah, they're using *an* MVCC snapshot. But it's not the transaction snapshot, it's one that postdates all sinval traffic the backend has received. Robert's changes to get rid of SnapshotNow didn't really affect this issue at all. (To clarify: I'm worried about all the stuff that involves syscache consultations; those queries executed via SPI are not the issue.) It now strikes me that it might be possible to use Andreas' logical decoding infrastructure to allow pg_dump's backend to operate with a "historical catalog snapshot", which perhaps could resolve this problem. But there's no such logic there today, and I have no idea what the disadvantages might be. > Certainly there's a comment about that > happening for pg_get_constraintdef_worker(), and other parts appear to > go through SPI, but not everything does. Yeah, Jan originally had a plan of making ruleutils operate exclusively through SPI, but that lasted probably about a month and a half before people started using syscache-accessing shortcuts. I think we really would be best off to eliminate the SPI usage there altogether; it has little effect except to waste cycles and mislead the credulous into thinking ruleutils operates in userspace. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
