On Wed, Dec 05, 2012 at 07:43:08PM -0500, Tom Lane wrote: > Robert Haas <robertmh...@gmail.com> writes: > > On Tue, Dec 4, 2012 at 3:38 PM, Jeff Davis <pg...@j-davis.com> wrote: > >> After reading that thread, I still don't understand why it's unsafe to > >> set HEAP_XMIN_COMMITTED in those conditions. Even if it is, I would > >> think that a sufficiently narrow case -- such as CTAS outside of a > >> transaction block -- would be safe, along with some slightly broader > >> cases (like BEGIN; CREATE TABLE; INSERT/COPY). > > > I haven't looked at the committed patch - which seemed a bit > > precipitous to me given the stage the discussion was at - but I > > believe the general issue with HEAP_XMIN_COMMITTED is that there might > > be other snapshots in the same transaction, for example from open > > cursors. > > From memory, the tqual.c code assumes that any tuple with XMIN_COMMITTED > couldn't possibly be from its own transaction, and thus it doesn't make > the tests that would be appropriate for a tuple that is from the current > transaction. Maybe it's all right anyway (i.e. if we should always treat > such a tuple as good) but I don't recall exactly what's tested in those > paths.
I don't see semantics preservable by freezing, yet omitting HEAP_XMIN_COMMITTED. The "HeapTupleHeaderGetCmin(tuple) >= snapshot->curcid" test is the one at risk. HeapTupleSatisfiesMVCC() does skip that test for HEAP_XMIN_COMMITTED tuples, but seeing xmin==FrozenTransactionId hampers it all the more. What if one of the preconditions for the optimization were the equivalent of CheckTableNotInUse()? I cannot immediately think of a older-cmin-scan source not caught thereby. Unmodified HeapTupleSatisfiesMVCC() will then suffice. Happily, it's not a restriction users will regularly encounter. Thanks, nm -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
