For 9.2 we discussed having COPY setting tuples as frozen. Various
details apply.
Earlier threads: "RFC: Making TRUNCATE more "MVCC-safe" "COPY with hints, rebirth"
I was unhappy with changing the behaviour of TRUNCATE, and still am.
So the proposal here is to have a specific modifier on TRUNCATE
command that makes it MVCC safe by throwing a serialization error.
That new behaviour should be requestable by adding the SERIALIZABLE
keyword.
i.e. TRUNCATE foo SERIALIZABLE;
This then allows a new style of TRUNCATE, yet without modiying
behaviour of earlier programs (ugh!).
(Once we have this, somebody that cares more than me may wish to
discuss deprecation of existing TRUNCATE behaviour in favour of this
new behaviour. I am not suggesting that here, nor do I even see a
reason for that at present.)
As soon as we have TRUNCATE SERIALIZABLE we can then enable normal
COPY to set tuples as frozen when
1) no earlier snapshots exist in the current transaction - since they
might see frozen tuples loaded in a later command and thus cause MVCC
violation
2) table has been truncated in this subtransaction by a TRUNCATE SERIALIZABLE
That then means the optimization would be available for normal data
loads/reloads.
This looks like a fairly neat way to allow MVCC-aware TRUNCATE for
those that want it, without affecting existing code and yet speeding
up large loads.
(Note that I am not suggesting any change to existing CREATE TABLE
behaviour. If you want this optimization, just add in TRUNCATE
SERIALIZABLE).
Thoughts?
-- Simon Riggs http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
