From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-committers(at)lists(dot)postgresql(dot)org |
Subject: | Re: pgsql: Fix table rewrites that include a column without a default. |
Date: | 2019-10-16 09:48:36 |
Message-ID: | 20191016094836.nh3akqg2j72wncnz@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
Hi,
On 2019-10-10 17:16:08 -0400, Tom Lane wrote:
> If you just want to verify that a rewrite happened or didn't happen,
> seems like you could check whether the table's relfilenode changed.
>
> regression=# select relfilenode as oldfilenode from pg_class where relname = 'rewrite_test'
> regression-# \gset
> regression=# select relfilenode != :oldfilenode as changed from pg_class where relname = 'rewrite_test';
> changed
> ---------
> f
> (1 row)
> regression=# alter table rewrite_test alter column notempty3_norewrite type bigint;
> ALTER TABLE
> regression=# select relfilenode != :oldfilenode as changed from pg_class where relname = 'rewrite_test';
> changed
> ---------
> t
> (1 row)
This felt verbose to me over a number of to-be-tested statements, so I
instead replaced it with a plpgsql function that EXECUTEs the DDL and
returns whether a rewrite happened. I'll assume/hope that that fixes the
occasional bf failures.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2019-10-16 09:48:37 | pgsql: Replace alter_table.sql test usage of event triggers. |
Previous Message | Michael Paquier | 2019-10-16 06:11:06 | pgsql: Refresh some incorrect links in pg_crc.c/h |