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 1rruaF-003W54-LJ for pgsql-hackers@arkaria.postgresql.org; Wed, 03 Apr 2024 06:58:56 +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 1rruaE-00G2Ph-A7 for pgsql-hackers@arkaria.postgresql.org; Wed, 03 Apr 2024 06:58:54 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rruaD-00G2PZ-VL for pgsql-hackers@lists.postgresql.org; Wed, 03 Apr 2024 06:58:54 +0000 Received: from fout6-smtp.messagingengine.com ([103.168.172.149]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rrua7-000JeO-71 for pgsql-hackers@lists.postgresql.org; Wed, 03 Apr 2024 06:58:52 +0000 Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailfout.nyi.internal (Postfix) with ESMTP id 28B3E13800E0; Wed, 3 Apr 2024 02:58:46 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Wed, 03 Apr 2024 02:58:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1712127526; x= 1712213926; bh=EzJ7BN8dQk8DOsnHpKOWCRjNjusxzwrGg/wGS1Mw2TM=; b=h wvA8s1UJkD2eNJon0HFTZbY4QXR88qzDNMmGweG8EqjlmZ0ltMBEKqJURL73rkG9 DIfJH0icYFva4qft/3h+Pz5q3ITU+1s7mv/r02B5+oca/5YXJtvelDj24ISsv6U4 zWuCTzDRjfNNm7QaVuU5XZN2bDFRHdl07xpoKRmhgxbswXpWxwtOj4yeJx9IWE2F KpGLWcEhmeC2biLpFnWr43KzUH7/63Hq4F/zlfh0/s6yjbNZo7onJhLsX90Kg0an 4/3NqcyVFgmIRhWHwF/1hzbexS/Fj90B6BKJj5op20LPN6vv/W+7ibw5dzEZ9gOp epMCBu0bjkOS4+IfLE9ow== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrudeffedguddufecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvvefukfggtggugfgjsehtkeertddttdejnecuhfhrohhmpeetlhhv rghrohcujfgvrhhrvghrrgcuoegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorh hgqeenucggtffrrghtthgvrhhnpedvkedtffduffdtffffheffhfejjefhgfeiueeukeej keffgfdufffhudffffeuveenucffohhmrghinhepvghnthgvrhhprhhishgvuggsrdgtoh hmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghl vhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh X-ME-Proxy: Feedback-ID: ia2694551:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 3 Apr 2024 02:58:44 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alvh.no-ip.org; s=schmee; t=1712127521; bh=C/333zzwkNTf8dgAKr47RA0PcsO3vs7NmBEDM0ZTMRQ=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=nLu+hi00Q03sA4td7s6gyl973OGud/hHtlhdnEf05OSN0j5Iub2U+C0zlCSNo0ogx N3kwGUyeGYE09xM83Mh7EEDZTT5yDDBwuU008hfOZz3vwpaR9Ccq4eg1kZpwsPj3Xu jJIdkmdvCqDQ6ULMkNxr6+roy53ea5OeKE1Bf7lF+6AWB4YdQYWTW1TKPuDuAyAayb qVrdMEJncwHRCBhv433S330jiTDnKROSIPu+v6AZo4D83MT8RUAHYJM/MsMOoKRujd Rohr1RYqxyiNwf2S31KD0GRumAP/8TOf8Szk6h/C4l9UR8AYn4Agw5lf573I4t8RKZ QqATruXGSiTkA== Received: by schmee.alvh.no-ip.org (Postfix, from userid 1000) id 0FF7641E; Wed, 3 Apr 2024 08:58:41 +0200 (CEST) Date: Wed, 3 Apr 2024 08:58:41 +0200 From: Alvaro Herrera To: Alexander Korotkov Cc: Bharath Rupireddy , Kartyshov Ivan , Euler Taveira , Thomas Munro , Peter Eisentraut , Amit Kapila , Dilip Kumar , Peter Smith , pgsql-hackers@lists.postgresql.org Subject: Re: [HACKERS] make async slave to wait for lsn to be replayed Message-ID: <202404030658.hhj3vfxeyhft@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hello, I noticed that commit 06c418e163e9 uses waitLSN->mutex (a spinlock) to protect the contents of waitLSN -- and it's used to walk an arbitrary long list of processes waiting ... and also, an arbitrary number of processes could be calling this code. I think using a spinlock for this is unwise, as it'll cause busy-waiting whenever there's contention. Wouldn't it be better to use an LWLock for this? Then the processes would sleep until the lock is freed. While nosing about the code, other things struck me: I think there should be more comments about WaitLSNProcInfo and WaitLSNState in waitlsn.h. In addLSNWaiter it'd be better to assign 'cur' before acquiring the lock. Is a plan array really the most efficient data structure for this, considering that you have to reorder each time you add an element? Maybe it is, but wouldn't it make sense to use memmove() when adding one element rather iterating all the remaining elements to the end of the queue? I think the include list in waitlsn.c could be tightened a bit: @@ -18,28 +18,18 @@ #include #include "pgstat.h" -#include "fmgr.h" -#include "access/transam.h" -#include "access/xact.h" #include "access/xlog.h" -#include "access/xlogdefs.h" #include "access/xlogrecovery.h" -#include "catalog/pg_type.h" #include "commands/waitlsn.h" -#include "executor/spi.h" #include "funcapi.h" #include "miscadmin.h" -#include "storage/ipc.h" #include "storage/latch.h" -#include "storage/pmsignal.h" #include "storage/proc.h" #include "storage/shmem.h" -#include "storage/sinvaladt.h" -#include "utils/builtins.h" #include "utils/pg_lsn.h" #include "utils/snapmgr.h" -#include "utils/timestamp.h" #include "utils/fmgrprotos.h" +#include "utils/wait_event_types.h" -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/ "Las cosas son buenas o malas segun las hace nuestra opinión" (Lisias)