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.96) (envelope-from ) id 1w79le-0050qX-2R for pgsql-hackers@arkaria.postgresql.org; Mon, 30 Mar 2026 10:22:46 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w79lc-002Xhf-3A for pgsql-hackers@arkaria.postgresql.org; Mon, 30 Mar 2026 10:22:45 +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.96) (envelope-from ) id 1w79lc-002XhX-2I for pgsql-hackers@lists.postgresql.org; Mon, 30 Mar 2026 10:22:45 +0000 Received: from mail-pg1-x534.google.com ([2607:f8b0:4864:20::534]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1w79lZ-00000001yY4-04yw for pgsql-hackers@lists.postgresql.org; Mon, 30 Mar 2026 10:22:43 +0000 Received: by mail-pg1-x534.google.com with SMTP id 41be03b00d2f7-b6ce6d1d3dcso1514462a12.3 for ; Mon, 30 Mar 2026 03:22:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1774866159; cv=none; d=google.com; s=arc-20240605; b=CzRe8yDC/K0T47w1OaGqU22MJMMFrDbwRvSh6YfIMUdqz0LlBvqOVZpPjc0PZAaDqh FOm5PV94JFU6JdFblw/vf69/cJ2GONhnrEpM9wh7ZTyNnWA8aEpQVtTxhnH9c04ULS/e VneIiS1N377eLU30HJud/wCk9hE5X0aFfIbaKPm8kKOLCBY78D256vdkl49QSXVCAfaT Kojim0DwI8KdMOUmfsIKWfC0Zmp6fyHBhvLZWce1YIhu52uah3BoHFAXwL7tvW0q4QD0 b+T6rtIpesPWmhHsGI12LipoVOpQajPpXsvhDLS1R/Gwhkh8Cxqd/29KJZ8mK3S2Uwvv yleQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=mnoEJJRhGeIgU8/0i5aQQacAImnCxX3eIIuKpwUXQsA=; fh=RcW6a29PJ8/vWWASBkP7Qgcva6th6gHYwZQ/ImKV9RQ=; b=AMgXfVGAAH0czewwWNwUNdYRclzhuK0FH/fK7keJol2vOP+YoUKTbPJOIiROD0KDmo h6VPN0+BADNxx55YKFy8UihPC4j6IafHVXcHORdsUtm6O+TPN4sPSfu+T0aKzI/QU9Bv VBj9GWFPJ9/29nrdPOirv4TngI0s8YE7nRAqp/+kk21IIkGaMpoxC96nHwW4y6eNeufd RPMPGvLK8xDNH3vpiajp5uf2WlbIngG8aA9wxCRM1NR/d4YXkBk6SzNMu2lxA80CBwwc k85I3p1/cQF9u/AZXSfoyz1vH86co/OKxgZXMSuOPTUlaHXS8QfJgAf8+wozrsbK+qhL eu9A==; darn=lists.postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1774866159; x=1775470959; darn=lists.postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=mnoEJJRhGeIgU8/0i5aQQacAImnCxX3eIIuKpwUXQsA=; b=iLL8W1Kf9gw/iXMUyFzM18VeqL2ubMIx52LwkjWxd+BIWekmtZJ4AjEYGYDZWO9n6P ogKnDxl4jgiOBhYrTA6znlwPtzpHfYS+PB//7fgFK2GnNCdRGebaNTZYKKrdBIT8UTZa To54jpU/15tye/CSsUIAxh2ywvD206eyP/6qqSmLpjizxPIQ1QzkA/RckBrhbRcBHBKN kDD2Xct1pMmP//XuJ75g7qSeXO5NyfDGbfpSXtJSUuLbqdVQz6B0saAnngl+/STHHTha ib0qW7inJrzF5V4vPS4S2R66lDzZyymDQo1KRersOrQHpvsc5UQ2olkCBu41kBYJxlQ2 UE+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774866159; x=1775470959; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=mnoEJJRhGeIgU8/0i5aQQacAImnCxX3eIIuKpwUXQsA=; b=N2RzwZWmPf6BnK768SogInoICgOsJ0LGXLXEU9CFUjvQA0JECEQohq7QycbbDqn+y9 fs87ffkOGb4MdzvZb2bxBVXW8fXtkRZ8nlq8fv+dBj14WdIKeBq/fm3BCCyLk/3qUwqn fZ3GTdSLs5tvsPpz+jgvuEItXeGB0eKkGXlkv0fAQFwwgSpAchjaK4mTu3IIy7oHERft 4FPaCjzItEhgeIuAlx8VE401c1APy6QJYeei67UZ0z82xlwfm0/8cPoOP/wHUh8OFZJ8 cJHTglYFS+UDKQZWOv3iR1fvmUPSrPUSFf219XSIXyA9QW2SRW60iF2u33APaP5jRNPB KBIQ== X-Forwarded-Encrypted: i=1; AJvYcCURo8U0Y3zKxt6lMC+OmUleysCYPNkNoI88nzzhkSns7sHx7TTH8meQxlCgj3WoVFlm+KLhhWFyz9SjCMdO@lists.postgresql.org X-Gm-Message-State: AOJu0Yz3+ANWuneAKEpR+IYFOSnc5Qo7ChoiM2MyTs2/8cpnY+MRp4lT 927wn0SNTR7yrlQ1XqM7BEec9wiEodnU2PnWI5ExVKpu8WDf1ZHxkSuc1qJZv7c4CNNZBArxhDw SYNBLDELHHE8PH3iL5BolW/4ibD74fL0= X-Gm-Gg: ATEYQzwbjO1xGaLzscx9VXnJWEoKV9hCVtUG1D39IjpPdTG8/SesiGWXgh0Wnf+cHxJ 1eNGBr0Lv1tYi4WYS194RbHDzN2r28lNt0eH6xvpTSHQ4s7i7xPv9romKnWwdNi9l19UZDiUi+z grp7SbGmXSy0g7q54cTj0A6AFcU4twxHu9B4KQoGXSWmkTO1XyjYeP48+I90kpEYfuotUcB21sn kzScHbNGL3koB5ZzHqxtbWbYImDwFgrwMx/pSQRIw/ojT7dR6T1WGnxLGJ8d7wo28xDxwKRfdZQ 5gkpVv1oIdpA0Hga1Bd+mzAFZKd4+wq9ZdRHUHIQK5wuHFJ/sIapAg== X-Received: by 2002:a05:6a21:6d84:b0:39b:91d1:6bf3 with SMTP id adf61e73a8af0-39c87b38a1cmr11525319637.56.1774866158947; Mon, 30 Mar 2026 03:22:38 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: shveta malik Date: Mon, 30 Mar 2026 15:52:26 +0530 X-Gm-Features: AQROBzCFoOe3QMqM0rH0B9FXICPswWAf6irAi15gqyE3NAwDYuyjrtINEXeMW18 Message-ID: Subject: Re: Use SIGTERM instead of SIGUSR1 for slotsync worker to exit during promotion? To: Nisha Moond Cc: Fujii Masao , Amit Kapila , PostgreSQL Hackers , shveta malik Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Mon, Mar 30, 2026 at 9:48=E2=80=AFAM Nisha Moond wrote: > Thanks for the patch Nisha. Few trivial things: 1) + * Signal handler called (in signal context) when PROCSIG_SLOTSYNC_MESSAGE + * is received. Sets the SlotSyncShutdownPending flag so that ProcessInterrupts() + * will dispatch to ProcessSlotSyncMessage() at the next safe point. */ +void +HandleSlotSyncMessageInterrupt(void) Can we please change the comment to below. Below suggestion is based on how we have written comments atop other such Handle*() functions /* * Handle receipt of an interrupt indicating a slotsync shutdown message * * This is called within SIGUSR1 handler. All we do here is set a flag * that will cause the next CHECK_FOR_INTERRUPTS() to invoke * ProcessSlotSyncMessage(). */ 2) I tried to consider whether 'stopSignaled' alone would be sufficient for our purposes, and whether we really need 'SlotSyncShutdownPending'. It seems that relying solely on stopSignaled could be problematic: a) stopSignaled resides in shared memory, so once it is set, it becomes visible to all other processes. If another process executes ProcessInterrupts(), it might incorrectly start handling slot sync shutdown. While this could be made to work, it would require extra checks to ensure that only the actual synchronizing process reacts. b) Unlike SlotSyncShutdownPending, we cannot reset stopSignaled, since it is also used to handle race conditions between the postmaster and promotion by the startup process. c) Accessing stopSignaled requires acquiring a mutex. It is unclear if that is a good idea in ProcessInterrupts(), since every time a process calls CHECK_FOR_INTERRUPTS(), it would need to acquire the mutex to decide whether to execute ProcessSlotSyncMessage(). Given these considerations, I think it makes sense to retain both stopSignaled and SlotSyncShutdownPending, but we should add a comment above SlotSyncShutdownPending explaining why stopSignaled alone is not sufficient. Let me know if others have different opinions here. thanks Shveta