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

From Hayato Kuroda (Fujitsu)
Subject RE: Conflict detection for update_deleted in logical replication
Date
Msg-id TYAPR01MB56928D16EA9AA27477D1631CF5552@TYAPR01MB5692.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: Conflict detection for update_deleted in logical replication  (Michail Nikolaev <michail.nikolaev@gmail.com>)
List pgsql-hackers
Dear Mikhail,

Thanks for the reply!

> > Anyway, this topic introduces huge complexity and is not mandatory for update_deleted
> > detection. We can work on it in later versions based on the needs.
>
> From my perspective, this is critical for databases. REINDEX CONCURRENTLY is typically run
> in production databases on regular basic, so any master-master system should be unaffected by it.

I think you do not understand what I said correctly. The main point here is that
the index scan is not needed to detect the update_deleted. In the first version
workers can do the normal sequential scan instead. This workaround definitely does
not affect REINDEX CONCURRENTLY.
After the patch being good shape or pushed, we can support using the index to find
the dead tuple, at that time we can consider how we ensure the index contains the entry
for dead tuples.

Best regards,
Hayato Kuroda
FUJITSU LIMITED


pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Cleanup SubPlanstate
Next
From: Andy Fan
Date:
Subject: Re: Avoid detoast overhead when possible