Robert Haas <> writes:
> On Thu, Apr 14, 2016 at 1:01 PM, Andres Freund <> 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 (
To make changes to your subscription:

Reply via email to