Re: Conflict detection for update_deleted in logical replication
| От | Dilip Kumar |
|---|---|
| Тема | Re: Conflict detection for update_deleted in logical replication |
| Дата | |
| Msg-id | CAFiTN-t4hq3jG4jGH4bwRW-Z233_UrWmWS43EpNt8ajPKxeq=g@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Conflict detection for update_deleted in logical replication (Amit Kapila <amit.kapila16@gmail.com>) |
| Ответы |
Re: Conflict detection for update_deleted in logical replication
|
| Список | 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.В списке pgsql-hackers по дате отправления: