On Tue, 2012-06-12 at 08:42 -0400, Robert Haas wrote:
> Instead of trying to maintain MVCC semantics, maybe we should just
> have something like COPY (FROZEN) that just writes frozen tuples into
> the table and throws MVCC out the window. Seems like that would be a
> lot easier to implement and satisfy basically the same use cases.
The reason that doesn't work is because there's really no answer for
ABORTs except to delete the whole table, or ask the user to try to
figure out what made it or what didn't. (That I can see, anyway; you may
have a better idea.)
In practice, I think the user would need to use this only for new tables
and use only one loader so they would know what to do if there is an
abort. That makes this very similar to the proposal for optimizing loads
by the transaction that creates the table; except with fewer safeguards.
It's basically just saying "don't abort, and be careful with concurrent
reads (which are now dirty)".
I think this problem largely has to do with freezing though, because
that's what makes it impossible to differentiate after an abort. Let's
set that aside for now, and just focus on setting HEAP_XMIN_COMMITTED,
PD_ALL_VISIBLE, and the VM bit. Those account for a major part of the
problem; being able to freeze also is really a bonus (and if the table
is really that static, then maybe creating it in the loading transaction
is reasonable).
In those terms, we can reframe the questions as: what do we do about
reads during the load?
Answers could include: (a) nothing -- reads during a load are potentially dirty (b) readers ignore hint bits during the
load,and pay the penalty (c) allow only INSERT/COPY, and block unsafe SELECT/UPDATE/DELETE
(a) is your proposal except without the freezing. (b) was my proposal.
(c) was a backup I had in mind (if reads are expensive anyway, maybe
people would rather just block).
These aren't exclusive. Maybe we can do (c) in READ COMMITTED and above,
and (a) in READ UNCOMMITTED.
Regards,Jeff Davis