Yes, the existing "ProcArrayGetReplicationSlotXmin" function has met the functional requirements and I have updated it in the attachment.
Changhong Fei
------------------ Original ------------------
From: "zhihuifan1213" <zhihuifan1213@163.com>;
Date: Wed, Nov 29, 2023 03:50 PM
To: "费长红"<feichanghong@qq.com>;
Cc: "pgsql-bugs"<pgsql-bugs@lists.postgresql.org>;
Subject: Re: 回复： BUG #18213: Standby's repeatable read isolation level transaction encountered a "nonrepeatable read" problem
"费长红" <feichanghong@qq.com> writes:
> -------------------------------------------------------------------------------------------------------------------------
>
> * 起个啥名好呢
> feichanghong@qq.com
>
> Indeed, I simply implemented and verified the solution. In the above test, the "create index" command on RW will hang
> until the transaction on standby is committed or aborted.
I think this is acceptable since its behavior is same as we wait for the
transactions in primary.
> In addition, even if there is no select query on the standby, RW's "create index" command may wait for a period of time,
> which affected by the wal_receiver_status_interval parameter.
The "wait" happens at the very last of index building, so the building
stages gives an enough time for standby to exceeds the xmin, so in a
real case, I think the overhead will be pretty low.
> You can see attachment for the patch.
I take a look at the that, function GetReplicationSlotXmin should be not
needed. You can use ProcArrayGetReplicationSlotXmin directly.
After searching the caller of WaitForOlderSnapshots, I think this bug
probably has impact on "deteach partition concurrently" / "reindex
concurrently" features. All of them needs the same fix.
--
Best Regards
Andy Fan