From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
---|---|
To: | feichanghong(at)qq(dot)com |
Cc: | zhihuifan1213(at)163(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #18213: Standby's repeatable read isolation level transaction encountered a "nonrepeatable read" problem |
Date: | 2023-12-06 02:32:35 |
Message-ID: | 20231206.113235.1021799318420598450.horikyota.ntt@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
At Tue, 5 Dec 2023 19:47:27 +0800, "费长红" <feichanghong(at)qq(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andrei Lepikhov | 2023-12-06 04:46:08 | Re: BUG #16925: ERROR: invalid DSA memory alloc request size 1073741824 CONTEXT: parallel worker |
Previous Message | Tom Lane | 2023-12-05 15:26:13 | Re: BUG #18229: Multiple vacuum queries fail after upgrading to 13.10 |