On Fri, Apr 15, 2016 at 2:51 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Thu, Apr 14, 2016 at 1:01 PM, Andres Freund <andres@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.
I think that we could have an alternate set of functions which have
the same interface as the syscache functions but using the transaction
snapshot and don't actually cache anything, and it would be fine for
what the pg_dump support functions need. It wouldn't be nearly as
fast as the actual syscache, but server-side CPU when deparsing DDL
has never really been a problem to my knowledge. I mean, if we had
something like this, it could also be sped up by adding a cache that
is flushed when the snapshot changes, but I'm not very sure we really
need to go that far.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
