From: | Bernd Helmle <mailings(at)oopsware(dot)de> |
---|---|
To: | 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: COPY TO returning empty result with parallel ALTER TABLE |
Date: | 2014-11-04 18:23:21 |
Message-ID: | D19B4DF60D3D403C6E7B61D6@eje.credativ.lan |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-general pgsql-hackers |
--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.
--
Thanks
Bernd
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2014-11-04 18:28:30 | Re: BUG #11867: Strange behaviour with composite types after resetting database tablespace |
Previous Message | Tom Lane | 2014-11-04 16:45:51 | Re: BUG #11867: Strange behaviour with composite types after resetting database tablespace |
From | Date | Subject | |
---|---|---|---|
Next Message | Brent Wood | 2014-11-04 18:43:38 | Postgres char type inconsistency |
Previous Message | Stephen Frost | 2014-11-04 17:46:11 | Re: Tablespace limit feature |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2014-11-04 18:28:30 | Re: BUG #11867: Strange behaviour with composite types after resetting database tablespace |
Previous Message | Andrew Dunstan | 2014-11-04 18:15:54 | Re: get_cast_func syscache utility function |