Re: COPY .. FREEZE, (apparently) not working on 9.6

From: Danilo Olivares <danilo(at)evicertia(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: COPY .. FREEZE, (apparently) not working on 9.6
Date: 2017-04-26 00:39:00
Message-ID: CAL1xy3X=8YsCnA3zcqWCYro24pnpqFycoQqF4huUzxg1Q+zXgQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

The value of infomask indicates freezed.

Thanks for your very helpful explanation!!

2017-04-26 1:48 GMT+02:00 Andres Freund <andres(at)anarazel(dot)de>:

> On 2017-04-26 01:40:40 +0200, Danilo Olivares wrote:
> > Hello,
> >
> > While testing "COPY/ FREEZE" feature, I've found a weird issue, by which
> I
> > am unable to actually freeze the rows/tables when using psql 9.6. Or, at
> > least, so it looks when inspecting 'xmin'..
> >
> > Here is the actual (failing) output from running a simple COPY/FREEZE
> > snippet against postgres 9.6.2 (x86_64) on CentOS:
> >
> > # /usr/pgsql-9.6/bin/psql -U postgres -h localhost
> > postgres=# BEGIN;
> > BEGIN
> > postgres=# CREATE TABLE da (text text);
> > CREATE TABLE
> > postgres=# COPY da FROM STDIN WITH (DELIMITER ',', FREEZE);
> > sample
> > \.
> > COPY 1
> > postgres=# COMMIT;
> > COMMIT
> > postgres=# select xmin,xmax from da;
> > xmin | xmax
> > —----+------
> > 1679 | 0
> > (1 row)
>
> These days xmin still shows the pre-frozen value, even if a tuple is
> frozen. That's for forensic purposes, so we can freeze more
> aggressively. You'd have to use the pageinspect extension to verify
> whether it's actually frozen.
>
> - Andres
>

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Michael Paquier 2017-04-26 01:24:40 Re: Concurrent ALTER SEQUENCE RESTART Regression
Previous Message Andres Freund 2017-04-25 23:48:21 Re: COPY .. FREEZE, (apparently) not working on 9.6