Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1r8FZI-008yzr-G2 for pgsql-bugs@arkaria.postgresql.org; Wed, 29 Nov 2023 08:05:12 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1r8FZD-009VLr-Sm for pgsql-bugs@arkaria.postgresql.org; Wed, 29 Nov 2023 08:05:07 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1r8FZD-009VLi-Js for pgsql-bugs@lists.postgresql.org; Wed, 29 Nov 2023 08:05:07 +0000 Received: from m12.mail.163.com ([220.181.12.199]) by magus.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1r8FZ2-0098dT-Im for pgsql-bugs@lists.postgresql.org; Wed, 29 Nov 2023 08:05:05 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=From:Subject:Date:Message-ID:MIME-Version: Content-Type; bh=To0whgieQCYrTLe6aGioVlJjLPSp3MdE0tRfgn0oNkU=; b=M2eunGfmCbDSuWzipIW4fxR0iOVszCEJVxeS/SDhI/hjjUJv1nJpHwXAthE6QR nUXpR53vTtPy30T4iOyE76jBX95Gva67fHqmqSJyIG4Bw4fzlhWqr/7FbsdkUOHk 1BXNkUELFlCkbTrotRx6nsuu627ohwIZygPcoHiMj2j5c= Received: from b97369165980 (unknown [140.205.118.144]) by zwqz-smtp-mta-g4-2 (Coremail) with SMTP id _____wDnVnST8GZlk7UAEQ--.49350S3; Wed, 29 Nov 2023 16:04:36 +0800 (CST) References: <18213-dbcf8d67b0e687f5@postgresql.org> <87cyvtkspj.fsf@163.com> User-agent: mu4e 1.10.7; emacs 29.1 From: zhihuifan1213@163.com To: =?utf-8?B?6LS56ZW/57qi?= Cc: pgsql-bugs Subject: Re: =?utf-8?B?5Zue5aSN77ya?= BUG #18213: Standby's repeatable read isolation level transaction encountered a "nonrepeatable read" problem Date: Wed, 29 Nov 2023 15:50:00 +0800 In-reply-to: Message-ID: <87zfyxj88c.fsf@163.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-CM-TRANSID: _____wDnVnST8GZlk7UAEQ--.49350S3 X-Coremail-Antispam: 1Uf129KBjvJXoW7Kw4rXryUuw1kXw17Xr1UKFg_yoW8JFyDpF W3GF1ftr1kJr1jk39Iyw1UJr4UAws8JryUJr1UJ3s7ur45Ar18tF1UtFWrtryUZrWxJF1j qr4Utrn8Jw1UA3DanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x0pEqg4XUUUUU= X-Originating-IP: [140.205.118.144] X-CM-SenderInfo: x2klx3xlid0iqsrtqiywtou0bp/xtbBhhY3U1c66okEQQAAs- List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk "=E8=B4=B9=E9=95=BF=E7=BA=A2" writes: > -------------------------------------------------------------------------= ------------------------------------------------ > > * =E8=B5=B7=E4=B8=AA=E5=95=A5=E5=90=8D=E5=A5=BD=E5=91=A2=20=20 > feichanghong@qq.com=20=20 >=20=20 > 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 "creat= e 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.=20 > 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.=20 --=20 Best Regards Andy Fan