From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bernd Helmle <mailings(at)oopsware(dot)de> |
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: [HACKERS] COPY TO returning empty result with parallel ALTER TABLE |
Date: | 2014-11-04 18:51:23 |
Message-ID: | 12887.1415127083@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-general pgsql-hackers |
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?
What concerns me more is whether there are other utility statements that
have comparable issues. We should not fix just COPY if there are more
cases.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | drickner | 2014-11-04 19:19:28 | BUG #11872: row height is not quite tall eneough |
Previous Message | Tom Lane | 2014-11-04 18:28:30 | Re: BUG #11867: Strange behaviour with composite types after resetting database tablespace |
From | Date | Subject | |
---|---|---|---|
Next Message | Alejandro Carrillo | 2014-11-04 19:09:16 | Re: Tablespace limit feature |
Previous Message | Brent Wood | 2014-11-04 18:43:38 | Postgres char type inconsistency |
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2014-11-04 19:32:52 | Re: WAL replay bugs |
Previous Message | Tom Lane | 2014-11-04 18:45:16 | Re: get_cast_func syscache utility function |