Andres Freund <andres@xxxxxxxxxxxxxxx> writes: > On 2014-11-04 13:51:23 -0500, Tom Lane wrote: >> Not sure. The OP's point is that in a SELECT, you do get unsurprising >> results, because a SELECT will acquire its execution snapshot after it's >> gotten AccessShareLock on the table. Arguably COPY should behave likewise. >> Or to be even more concrete, COPY (SELECT * FROM tab) TO ... probably >> already acts like he wants, so why isn't plain COPY equivalent to that? > Even a plain SELECT essentially acts that way if I recall correctly if > you use REPEATABLE READ+ and force a snapshot to be acquired > beforehand. It's imo not very surprising. "It doesn't fail in a non-default isolation mode" is hardly much of an argument for this being okay in READ COMMITTED. > All ALTER TABLE rewrites just disregard visibility of existing > tuples. Only CLUSTER/VACUUM FULL do the full hangups to keep all the > necessary tuples + ctid chains around. Yeah, and I think that it's entirely reasonable for rewriting ALTER TABLEs to update the xmin of the rewritten tuples; after all, the output data could be arbitrarily different from what the previous transactions put into the table. But that is not the question here. If the COPY blocks until the ALTER completes --- as it must --- why is its execution snapshot not taken *after* the lock is acquired? regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
