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 (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
