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

Поиск
Список
Период
Сортировка
От Dean Rasheed
Тема Re: Dump-restore loosing 'attnotnull' bit for DEFERRABLE PRIMARY KEY column(s).
Дата
Msg-id CAEZATCWZfdZVnsiJdCSZfMNsOSrTtEZ2gjiZ-HQoNc2FMYxGhA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Dump-restore loosing 'attnotnull' bit for DEFERRABLE PRIMARY KEY column(s).  (Aleksander Alekseev <aleksander@timescale.com>)
Ответы Re: Dump-restore loosing 'attnotnull' bit for DEFERRABLE PRIMARY KEY column(s).  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Список 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 по дате отправления:

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: Failures in constraints regression test, "read only 0 of 8192 bytes"
Следующее
От: 'Alvaro Herrera'
Дата:
Сообщение: Re: Some shared memory chunks are allocated even if related processes won't start