Re: [GENERAL] Re: [HACKERS] COPY TO returning empty result with parallel ALTER TABLE - Mailing list pgsql-bugs

From Bernd Helmle
Subject Re: [GENERAL] Re: [HACKERS] COPY TO returning empty result with parallel ALTER TABLE
Date
Msg-id FF3CF50F040B5D1AE1381AB1@localhost
Whole thread Raw
In response to Re: [GENERAL] Re: [HACKERS] COPY TO returning empty result with parallel ALTER TABLE  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs

--On 4. November 2014 17:18:14 -0500 Tom Lane <tgl@sss.pgh.pa.us> wrote:

> 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?

COPY waits in DoCopy() but its snapshot gets acquired in PortalRunUtility()
earlier. SELECT has it's lock already during transform/analyse phase and
its snapshot is taken much later.  Looks like we need something that
analyses a utility statement to get its lock before executing.

--
Thanks

    Bernd


pgsql-bugs by date:

Previous
From: drickner@indy.rr.com
Date:
Subject: BUG #11872: row height is not quite tall eneough
Next
From: Tom Lane
Date:
Subject: Re: ltree::text not immutable?