Re: Question about behavior of deletes with REPLICA IDENTITY NOTHING - Mailing list pgsql-hackers

From James Coleman
Subject Re: Question about behavior of deletes with REPLICA IDENTITY NOTHING
Date
Msg-id CAAaqYe8iRZeXTdbB1CUYsCq5zr=LLiM=_m9AgMzr1ethSP=TOw@mail.gmail.com
Whole thread Raw
In response to Re: Question about behavior of deletes with REPLICA IDENTITY NOTHING  (Laurenz Albe <laurenz.albe@cybertec.at>)
Responses Re: Question about behavior of deletes with REPLICA IDENTITY NOTHING
List pgsql-hackers
On Wed, Feb 7, 2024 at 3:22 PM Laurenz Albe <laurenz.albe@cybertec.at> wrote:
>
> On Wed, 2024-02-07 at 15:12 -0500, James Coleman wrote:
> > We recently noticed some behavior that seems reasonable but also
> > surprised our engineers based on the docs.
> >
> > If we have this setup:
> > create table items(i int);
> > insert into items(i) values (1);
> > create publication test_pub for all tables;
> >
> > Then when we:
> > delete from items where i = 1;
> >
> > we get:
> > ERROR:  cannot delete from table "items" because it does not have a
> > replica identity and publishes deletes
> > HINT:  To enable deleting from the table, set REPLICA IDENTITY using
> > ALTER TABLE.
> >
> > Fair enough. But if we do this:
> > alter table items replica identity nothing;
> >
> > because the docs [1] say that NOTHING means "Records no information
> > about the old row." We still get the same error when we try the DELETE
> > again.
>
> Well, "REPLICA IDENTITY NOTHING" is the same as "has no replica identity".
> So is "REPLICA IDENTITY DEFAULT" if there is no primary key, or
> "REPLICA IDENTITY USING INDEX ..." if the index is dropped.
>
> See "pg_class": the column "relreplident" is not nullable.

Right, I think the confusing point for us is that the docs for NOTHING
("Records no information about the old row") imply you can decide you
don't have to record anything if you don't want to do so, but the
publication feature is effectively overriding that and asserting that
you can't make that choice.

Regards,
James Coleman



pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: Rename setup_cancel_handler in pg_dump
Next
From: Nathan Bossart
Date:
Subject: Re: glibc qsort() vulnerability