BUG #18405: flaw in dump of inherited/dropped constraints

From: PG Bug reporting form <noreply(at)postgresql(dot)org>
To: pgsql-bugs(at)lists(dot)postgresql(dot)org
Cc: scott_ribe(at)elevated-dev(dot)com
Subject: BUG #18405: flaw in dump of inherited/dropped constraints
Date: 2024-03-23 18:09:02
Message-ID: 18405-4ce10e802e8d3174@postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

The following bug has been logged on the website:

Bug reference: 18405
Logged by: sribe
Email address: scott_ribe(at)elevated-dev(dot)com
PostgreSQL version: 16.2
Operating system: Linux &amp; macOS
Description:

Create the following schema:

create table t1 (c boolean not null);
create table t2 (c boolean) inherits (t1);
alter table t2 alter c drop not null;

------
Check it:

test=# \d t2
Table "public.t2"
Column | Type | Collation | Nullable | Default
--------+---------+-----------+----------+---------
c | boolean | | |
Inherits: t1

------
Dump it:

❯ pg_dump -s -t t1 -t t2 test
--
-- PostgreSQL database dump
--

-- Dumped from database version 14.2
-- Dumped by pg_dump version 16.2

SET ...

CREATE TABLE public.t1 (
c boolean NOT NULL
);

ALTER TABLE public.t1 OWNER TO sribe;

CREATE TABLE public.t2 (
c boolean
)
INHERITS (public.t1);

ALTER TABLE public.t2 OWNER TO sribe;

------
The drop of the not null constraint is not reflected in the dump. Thus
playing back the dump results in column c of table t2 having the not null
constraint.

But it's actually a bit weirder than that. I have been using:

pg_dump -Fc -Z0 mydb | bzip2 > <filename>

followed by:

bunzip2 -kc <filename> | pg_restore -v -d mydb

to load up a testing copy for a very long time. This worked from pretty old
versions all the way through 15, but broke in 16 because of the erroneous
not null constraint on a table. Yet going back to 14.2 (I don't currently
have 15 installed locally), the plain format dump has the problem of not
dropping the constraint. So it looks like prior to 16, plain dumps had this
problem, but custom format dumps did not.

One more thing, making the custom format dump using pg_dump 14, then
restoring with pg_restore 16, gets the erroneous not null constraint. (Dump
with 16 and restore with 14, is of course not possible.)

PG builds are nothing exotic. Linux: ./configure --with-openssl
--with-systemd --with-llvm --prefix=..., macOS: ./configure --without-icu
--with-llvm --prefix=...

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Janne Annala 2024-03-25 08:15:02 Re: NEW.* and OLD.* inside trigger function don't seem to contain recently added columns
Previous Message Alexander Korotkov 2024-03-23 11:37:04 Re: [BUG] false positive in bt_index_check in case of short 4B varlena datum