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.linnakangas@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-6DLqvoiibpkKhTLQfw@mail.gmail.com
Thanks,
nm
