Re: Dump-restore loosing 'attnotnull' bit for DEFERRABLE PRIMARY KEY column(s). - Mailing list pgsql-hackers

From Dean Rasheed
Subject Re: Dump-restore loosing 'attnotnull' bit for DEFERRABLE PRIMARY KEY column(s).
Date
Msg-id CAEZATCWZfdZVnsiJdCSZfMNsOSrTtEZ2gjiZ-HQoNc2FMYxGhA@mail.gmail.com
Whole thread Raw
In response to Re: Dump-restore loosing 'attnotnull' bit for DEFERRABLE PRIMARY KEY column(s).  (Aleksander Alekseev <aleksander@timescale.com>)
Responses Re: Dump-restore loosing 'attnotnull' bit for DEFERRABLE PRIMARY KEY column(s).
List pgsql-hackers
On Mon, 4 Mar 2024 at 12:34, Aleksander Alekseev
<aleksander@timescale.com> wrote:
>
> > This was an experimental patch, I was looking for the comment on the proposed
> > approach -- whether we could simply skip the throwaway NOT NULL constraint for
> > deferred PK constraint.  Moreover,  skip that for any PK constraint.
>
> I confirm that the patch fixes the bug. All the tests pass. Looks like
> RfC to me.
>

I don't think that this is the right fix. ISTM that the real issue is
that dropping a NOT NULL constraint should not mark the column as
nullable if it is part of a PK, whether or not that PK is deferrable
-- a deferrable PK still marks a  column as not nullable.

The reason pg_dump creates these throwaway NOT NULL constraints is to
avoid a table scan to check for NULLs when the PK is later created.
That rationale still applies to deferrable PKs, so we still want the
throwaway NOT NULL constraints in that case, otherwise we'd be hurting
performance of restore.

Regards,
Dean



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: Failures in constraints regression test, "read only 0 of 8192 bytes"
Next
From: 'Alvaro Herrera'
Date:
Subject: Re: Some shared memory chunks are allocated even if related processes won't start