Re: 回复: BUG #18213: Standby's repeatable read isolation level transaction encountered a "nonrepeatable read" problem
От | zhihuifan1213@163.com |
---|---|
Тема | Re: 回复: BUG #18213: Standby's repeatable read isolation level transaction encountered a "nonrepeatable read" problem |
Дата | |
Msg-id | 87zfyxj88c.fsf@163.com обсуждение исходный текст |
Ответ на | BUG #18213: Standby's repeatable read isolation level transaction encountered a "nonrepeatable read" problem (PG Bug reporting form <noreply@postgresql.org>) |
Ответы |
Re: BUG #18213: Standby's repeatable read isolation level transaction encountered a "nonrepeatable read" problem
|
Список | pgsql-bugs |
"费长红" <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
В списке pgsql-bugs по дате отправления: