Re: BUG #18213: Standby's repeatable read isolation level transaction encountered a "nonrepeatable read" problem

Kyotaro Horiguchi <horikyota.ntt@gmail.com>

From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>

To: feichanghong@qq.com

Cc: zhihuifan1213@163.com, pgsql-bugs@lists.postgresql.org

Date: 2023-12-06T02:32:35Z

Lists: pgsql-bugs

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Fix timing-dependent failure in GSSAPI data transmission.
- d053a879bb36 17.0 cited

At Tue, 5 Dec 2023 19:47:27 +0800, "费长红" <feichanghong@qq.com> wrote in 
> Yes, the existing "ProcArrayGetReplicationSlotXmin" function has met the functional requirements and I have updated it in the attachment.


I'm not sure if it's valid to use slot xmin for this purpose. First
off, it overlooks standbys that don't use a slot. Also, inactive slots
can lead to unnecessary blocks on CREATE INDEX CONCURRENTLY. I'm not
entirely sure but we should avoid a situation that primary gets
blocked due to standby activities in asynchronous replication.
Finally, I honestly don't think we want to add another instance of
sleep-polling using pg_sleep() for this kind of wait.

We could add a variant of SyncRepWaitForLSN() for standby xmin for
synchronous replication.  However, as I mentioned earlier, I don't
think this approach is good for asynchronous replication. It might be
a good idea to handle it similarly to replication conflicts, by
canceling conflicting transactions on standbys. However, as of now, I
don't have a clear idea of the specific conditions that should trigger
conflist detection.

regards

-- 
Kyotaro Horiguchi
NTT Open Source Software Center