Robert Haas <robertmh...@gmail.com> writes: > On Thu, Apr 14, 2016 at 1:01 PM, Andres Freund <and...@anarazel.de> wrote: >> I'm not sure I find that convincing: The state portrayed by the syscache >> is th state COPY/SELECT et al will be using. I think the angle to >> attack this is rather to allow blocking 'globally visible' DDL >> efficiently and correctly, rather than the hack pg_dump is using right now.
> Maybe. I think that idea of changing the pg_get_Xdef() stuff to use > the transaction snapshot rather than the latest snapshot might be > worth considering, too. The problem here is the connection to syscache; changing the behavior of that, in a general context, is very scary. What we might be able to do that would satisfy pg_dump's needs is to invent a mode in which you can run a read-only transaction that uses the transaction snapshot to populate syscache (and then flushes the syscache at the end). It would have to be a pretty "hard" notion of read-only, not the squishy one we have now, but I think it would work safely. Anything that might otherwise break because of stale syscache entries should be prevented from having bad side-effects by the read-only restriction. regards, tom lane -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers