Re: Conflict detection for update_deleted in logical replication - Mailing list pgsql-hackers

From Dilip Kumar
Subject Re: Conflict detection for update_deleted in logical replication
Date
Msg-id CAFiTN-t4hq3jG4jGH4bwRW-Z233_UrWmWS43EpNt8ajPKxeq=g@mail.gmail.com
Whole thread Raw
In response to Re: Conflict detection for update_deleted in logical replication  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Conflict detection for update_deleted in logical replication
List pgsql-hackers
On Fri, Jan 3, 2025 at 4:31 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
On Thu, Jan 2, 2025 at 2:57 PM vignesh C <vignesh21@gmail.com> wrote:
>
> Conflict detection of truncated updates is detected as update_missing
> and deleted update is detected as update_deleted. I was not sure if
> truncated updates should also be detected as update_deleted, as the
> document says truncate operation is "It has the same effect as an
> unqualified DELETE on each table" at [1].
>

This is expected behavior because TRUNCATE would immediately reclaim
space and remove all the data. So, there is no way to retain the
removed row.

I’m not sure whether to call this expected behavior or simply acknowledge that we have no way to control it. Logically, it would have been preferable if it behaved like a DELETE, but we are constrained by the way TRUNCATE works. At least that's what my opinion about this case.

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Conflict detection for update_deleted in logical replication
Next
From: Ranier Vilela
Date:
Subject: Re: Fix misuse use of pg_b64_encode function (contrib/postgres_fdw/connection.c)