On Fri, Apr 15, 2016 at 2:51 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > 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.
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
