Re: COPY TO returning empty result with parallel ALTER TABLE

On 11/04/2014 01:51 PM, Tom Lane wrote:
> Bernd Helmle <mailings(at)oopsware(dot)de> writes:
>> --On 3. November 2014 18:15:04 +0100 Sven Wegener
>> <sven(dot)wegener(at)stealer(dot)net> wrote:
>>> I've check git master and 9.x and all show the same behaviour. I came up
>>> with the patch below, which is against curent git master. The patch
>>> modifies the COPY TO code to create a new snapshot, after acquiring the
>>> necessary locks on the source tables, so that it sees any modification
>>> commited by other backends.
>> Well, i have the feeling that there's nothing wrong with it. The ALTER
>> TABLE command has rewritten all tuples with its own XID, thus the current
>> snapshot does not "see" these tuples anymore. I suppose that in
>> SERIALIZABLE or REPEATABLE READ transaction isolation your proposal still
>> doesn't return the tuples you'd like to see.
> 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?

Yes, that seems like an outright bug.

cheers

andrew