Re: BUG #18213: Standby's repeatable read isolation level transaction encountered a "nonrepeatable read" problem
От | Kyotaro Horiguchi |
---|---|
Тема | Re: BUG #18213: Standby's repeatable read isolation level transaction encountered a "nonrepeatable read" problem |
Дата | |
Msg-id | 20231206.113235.1021799318420598450.horikyota.ntt@gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #18213: Standby's repeatable read isolation level transaction encountered a "nonrepeatable read" problem ("费长红" <feichanghong@qq.com>) |
Список | pgsql-bugs |
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 itin 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
В списке pgsql-bugs по дате отправления: