On Fri, Mar 02, 2012 at 08:46:45AM +0000, Simon Riggs wrote: > On Thu, Mar 1, 2012 at 8:49 PM, Heikki Linnakangas > <heikki.linnakan...@enterprisedb.com> wrote: > > It's still broken:
[BEGIN;TRUNCATE;SAVEPOINT;COPY;ROLLBACK TO] > So this approach isn't the one... > > The COPY FREEZE patch provides a way for the user to say explicitly > that they don't really care about these MVCC corner cases and as a > result allows us to avoid touching XidInMVCCSnapshot() at all. So > there is still a patch on the table. You can salvage the optimization by tightening its prerequisite: use it when the current subtransaction or a child thereof created or truncated the table. A parent subtransaction having done so is acceptable for the WAL avoidance optimization but not for this. A COPY FREEZE ignoring that stronger restriction would be an interesting feature in its own right, but it brings up other problems. For example, suppose you write a tuple, then fail while writing its index entries. The tuple is already frozen and visible, but it lacks a full set of live index entries. The subtransaction aborts, but the top transaction commits and makes the situation permanent. Incidentally, I contend that we should write frozen tuples to new/truncated tables unconditionally. The current behavior of making old snapshots see the table as empty violates atomicity at least as badly as letting those snapshots see the future-snapshot contents. But Marti has a sound proposal that would interact with your efforts here to avoid violating atomicity at all: http://archives.postgresql.org/message-id/cabrt9rbrmdsoz8kxgehfb4lg-ev9u67-6dlqvoiibpkkhtl...@mail.gmail.com 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