From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bernd Helmle <mailings(at)oopsware(dot)de>, 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: [BUGS] [HACKERS] COPY TO returning empty result with parallel ALTER TABLE |
Date: | 2014-11-04 20:03:28 |
Message-ID: | 20141104200328.GR28295@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-general pgsql-hackers |
On 2014-11-04 13:51:23 -0500, 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?
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.
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.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2014-11-04 20:36:09 | Re: BUG #11875: char() not behaving as documented |
Previous Message | b.wood | 2014-11-04 19:55:17 | BUG #11875: char() not behaving as documented |
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2014-11-04 20:10:11 | Re: Tablespace limit feature |
Previous Message | Sven Wegener | 2014-11-04 19:35:42 | Re: COPY TO returning empty result with parallel ALTER TABLE |
From | Date | Subject | |
---|---|---|---|
Next Message | Mikko Tiihonen | 2014-11-04 20:20:04 | Re: [JDBC] Pipelining executions to postgresql server |
Previous Message | Adam Brightwell | 2014-11-04 20:02:16 | Re: superuser() shortcuts |