Horton

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

Dean Rasheed <dean.a.rasheed@gmail.com>

View thread View on postgr.es
From: Dean Rasheed <dean.a.rasheed@gmail.com>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Aleksander Alekseev <aleksander@timescale.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>, Amul Sul <sulamul@gmail.com>, vignesh C <vignesh21@gmail.com>
Date: 2024-03-07T13:42:07Z
Lists: pgsql-hackers 
On Thu, 7 Mar 2024 at 13:00, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
>
> So I think the original developers of REPLICA IDENTITY had the right
> idea here (commit 07cacba983ef), and we mustn't change this aspect,
> because it'll lead to data corruption in replication.  Using a deferred
> PK for DDL considerations seems OK, but it seems certain that for actual
> data replication it's going to be a disaster.
>

Yes, that makes sense. If I understand correctly though, the
replication code uses relation->rd_replidindex (not
relation->rd_pkindex), although sometimes it's the same thing. So can
we get away with making sure that RelationGetIndexList() doesn't set
relation->rd_replidindex to a deferrable PK, while still allowing
relation->rd_pkindex to be one?

Regards,
Dean

Commits

  1. Revert structural changes to not-null constraints

  2. Admit deferrable PKs into rd_pkindex, but flag them as such

  3. Add the notion of REPLICA IDENTITY for a table.