Re: [GENERAL] Re: [BUGS] COPY TO returning empty result with parallel ALTER TABLE

From: Bernd Helmle <mailings(at)oopsware(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Sven Wegener <sven(dot)wegener(at)stealer(dot)net>, pgsql-hackers(at)postgresql(dot)org, pgsql-general(at)postgresql(dot)org, pgsql-bugs(at)postgresql(dot)org
Subject: Re: [GENERAL] Re: [BUGS] COPY TO returning empty result with parallel ALTER TABLE
Date: 2014-11-04 23:14:42
Message-ID: FF3CF50F040B5D1AE1381AB1@localhost
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-general pgsql-hackers

--On 4. November 2014 17:18:14 -0500 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2014-11-04 23:48:14 Re: ltree::text not immutable?
Previous Message Tom Lane 2014-11-04 22:18:14 Re: [GENERAL] Re: [HACKERS] COPY TO returning empty result with parallel ALTER TABLE

Browse pgsql-general by date

  From Date Subject
Next Message Rémy-Christophe Schermesser 2014-11-05 16:31:28 Performance problem on 2 PG versions on same query
Previous Message Tom Lane 2014-11-04 22:18:14 Re: [GENERAL] Re: [HACKERS] COPY TO returning empty result with parallel ALTER TABLE

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-11-04 23:48:14 Re: ltree::text not immutable?
Previous Message Alvaro Herrera 2014-11-04 22:28:22 Re: BRIN indexes - TRAP: BadArgument