--On 4. November 2014 17:18:14 -0500 Tom Lane 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 th
Andres Freund writes:
> On 2014-11-04 13:51:23 -0500, Tom Lane wrote:
>> 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.
On 2014-11-04 13:51:23 -0500, Tom Lane wrote:
> Bernd Helmle writes:
> > --On 3. November 2014 18:15:04 +0100 Sven Wegener
> > 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
> >> modifi
On Tue, 4 Nov 2014, Tom Lane wrote:
> Bernd Helmle writes:
> > --On 3. November 2014 18:15:04 +0100 Sven Wegener
> > 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 CO
On Tue, 4 Nov 2014, Bernd Helmle wrote:
> --On 3. November 2014 18:15:04 +0100 Sven Wegener
> 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 ne
On 11/04/2014 01:51 PM, Tom Lane wrote:
Bernd Helmle writes:
--On 3. November 2014 18:15:04 +0100 Sven Wegener
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 crea
Bernd Helmle writes:
> --On 3. November 2014 18:15:04 +0100 Sven Wegener
> 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 acquir
--On 3. November 2014 18:15:04 +0100 Sven Wegener
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 th
Hi all,
we experienced what seems to be a bug in the COPY TO implementation. When a
table is being rewritten by an ALTER TABLE statement, a parallel COPY TO
results in an empty result.
Consider the following table data:
CREATE TABLE test (id INTEGER NOT NULL, PRIMARY KEY (id));
INSERT INTO t
