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 1sRPPQ-00F3VE-SA for pgsql-hackers@arkaria.postgresql.org; Wed, 10 Jul 2024 04:58:29 +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 1sRPPP-0024Hh-Gz for pgsql-hackers@arkaria.postgresql.org; Wed, 10 Jul 2024 04:58:27 +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 1sRPPP-0024AM-3H for pgsql-hackers@lists.postgresql.org; Wed, 10 Jul 2024 04:58:27 +0000 Received: from mail.postgrespro.ru ([93.174.131.139]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sRPPM-001Kiy-V7 for pgsql-hackers@lists.postgresql.org; Wed, 10 Jul 2024 04:58:26 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mx2023; t=1720587503; bh=nyNpwsmRRatpIFXYO+Nn5J6fP+LbiU9kgJ/cUBBO2sE=; h=Date:From:To:Cc:Subject:In-Reply-To:References:User-Agent: Message-ID:From; b=AH2ki5NG4Jb2SeiBESkmykPYJPgj2tahBjmfUCULOMfNeNb6yI6Emwv0oiyVD123P hNcwCklyAn8/bi2rZ8OtzOnDDuF1n9RoZwaoP+KdjNPbXD8CWbxwZLaqSf/y8oKMaF T2EfTlCHLrnVqOiZwXJBye0BitnShOJSwh1NuXemSckKLkLeaeiVUFKYpl//kfm+5y ZWcWJeBBygtMzZwVleNlA+y7zZ5eUMo4WZeR0rKZMHdt1sb3xiqTex56/HTdRstSD8 PqAq39S9ecwNezwk8fzH/ERUx1Klu3xpHOqGpUKn8metw1iH9mDX2f44LSfuQ/zo01 H9PGPg4fGPsKQ== Received: from mail.postgrespro.ru (webmail.mstn.postgrespro.ru [192.168.2.26]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: i.kartyshov@postgrespro.ru) by mail.postgrespro.ru (Postfix/587) with ESMTPSA id 1A5BC60298; Wed, 10 Jul 2024 07:58:23 +0300 (MSK) MIME-Version: 1.0 Date: Wed, 10 Jul 2024 07:58:23 +0300 From: Kartyshov Ivan To: Kyotaro Horiguchi Cc: aekorotkov@gmail.com, hlinnaka@iki.fi, alvherre@alvh.no-ip.org, pashkin.elfe@gmail.com, bharath.rupireddyforpostgres@gmail.com, euler@eulerto.com, thomas.munro@gmail.com, peter@eisentraut.org, amit.kapila16@gmail.com, dilipbalaut@gmail.com, smithpb2250@gmail.com, pgsql-hackers@lists.postgresql.org Subject: Re: [HACKERS] make async slave to wait for lsn to be replayed In-Reply-To: <8d0286f9f0c2f9fc29794dda6b5f4600@postgrespro.ru> References: <20240620.173045.1163445432733259320.horikyota.ntt@gmail.com> <8d0286f9f0c2f9fc29794dda6b5f4600@postgrespro.ru> User-Agent: Roundcube Webmail/1.6.7 Message-ID: <50b33ec2bede8aea567557a7e78c6864@postgrespro.ru> X-Sender: i.kartyshov@postgrespro.ru Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-KSMG-AntiPhishing: NotDetected, bases: 2024/07/10 03:16:00 X-KSMG-AntiSpam-Interceptor-Info: not scanned X-KSMG-AntiSpam-Status: not scanned, disabled by settings X-KSMG-AntiVirus: Kaspersky Secure Mail Gateway, version 2.1.0.7854, bases: 2024/07/09 21:28:00 #25931284 X-KSMG-AntiVirus-Status: NotDetected, skipped X-KSMG-LinksScanning: not scanned, disabled by settings X-KSMG-Message-Action: skipped X-KSMG-Rule-ID: 1 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk >> I think the race condition you mentioned refers to the inconsistency >> between the inHeap flag and the pairing heap caused by a race >> condition between timeout and wakeup (or perhaps other combinations? >> I'm not sure which version of the patch the mentioned race condition >> refers to). However, I imagine it is difficult to reliably reproduce >> this condition. In that regard, in the latest patch, the coherence >> between the inHeap flag and the pairing heap is protected by LWLock, >> so I believe we no longer need that test. > > No, Alexandre means that Heikki point on race condition just before > LWLock. But injection point we can inject and stepin on backend, and > WaitLSNSetLatches is used from Recovery process. But I have trouble > to wakeup injection point on server. One more thing. I want to point, when you move injection point to contrib dir and do the same test (044_wal_replay_wait_injection_test.pl) step by step with hands, wakeup works well. -- Ivan Kartyshov Postgres Professional: www.postgrespro.com