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

From Michail Nikolaev
Subject Re: Conflict detection for update_deleted in logical replication
Date
Msg-id CANtu0ogCnFSDiWmb76PRqBL6BMyKD50tbASHtDAFNtu7CyjqMQ@mail.gmail.com
Whole thread Raw
In response to RE: Conflict detection for update_deleted in logical replication  ("Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>)
Responses RE: Conflict detection for update_deleted in logical replication
List pgsql-hackers
Hello Hayato!

> Note that apply workers can stop due to some reasons (e.g., disabling subscriptions,
> error out, deadlock...). In this case, the snapshot cannot eb registered by the
> worker and index can be re-built during the period.

However, the xmin of a slot affects replication_slot_xmin in ProcArrayStruct, so it might
be straightforward to wait for it during concurrent index builds. We could consider adding
a separate conflict_resolution_replication_slot_xmin to wait only for that.

> 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.

Best regards,
Mikhail.

pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: AIO writes vs hint bits vs checksums
Next
From: Tatsuo Ishii
Date:
Subject: Re: protocol-level wait-for-LSN