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 1wAJiW-002GXM-2S for pgsql-hackers@arkaria.postgresql.org; Wed, 08 Apr 2026 03:36:36 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wAJiU-004QEa-2k for pgsql-hackers@arkaria.postgresql.org; Wed, 08 Apr 2026 03:36:35 +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.96) (envelope-from ) id 1wAJiU-004QER-1P for pgsql-hackers@lists.postgresql.org; Wed, 08 Apr 2026 03:36:34 +0000 Received: from mail-oo1-xc2d.google.com ([2607:f8b0:4864:20::c2d]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wAJiT-000000019Wd-05AH for pgsql-hackers@lists.postgresql.org; Wed, 08 Apr 2026 03:36:34 +0000 Received: by mail-oo1-xc2d.google.com with SMTP id 006d021491bc7-67c22b05346so3227312eaf.2 for ; Tue, 07 Apr 2026 20:36:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1775619392; cv=none; d=google.com; s=arc-20240605; b=ZzdcLoDv4cpJAUMioSCdbRnc+r6yvaJP7kPrSZ1n1o5MFCecUrjNw3d0nAylo3WZjf EQxbi/j4EaIz7Ao1Mge3CjFTSaIPeiVaP1bNs3Hmi/AbrIUOPTfvA1R6td9qyL9G/wAr 4o7VLviMG4rFLTGHJyAuFY7/feXeaHdbczSGqPWJCrUP4VXCn/mVDnh9FJ0iDCbqUYqR HLXehPsh11TlSQjXARjRScRgmQNOS6IGXWEJ4rpzLqCdQ0PORXDfRiQxO7Qv5y/YCfHj oa3vxA9IrDxi4uQYg0R2GqCFqX78M+OQjsPyc+vJomRaixIWNDoR1CzqmlivbV5okF3I 2ZvA== 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=uff+TdcY/Nhu+JI2HDDKA3IabruJVxYTdOi16NU2Lwg=; fh=eGVnSYnrXaEjHOgEcyP9zFFSWUPRj59j82e1LoJg6B8=; b=SuEu6kbDaeaeU1SPrLN06z1wJgkCdYJO4wA0KGzZLznX77r19mcwJMmx4iCaxWPEBi nYdXmrAgjRS+aza7gdZj7eaCKK2WS9r1f086NcxfkoR1O/TnXZucpxeZqeRDZnKt9woC JMkWBYrJIcXaqoVPZQOzrkgJw2KgqhNnU+8vw+oWUbm/XYqe0RktTrDRJXZGabQjJrJQ NQj7JjIYvuIM3s3icNi/bWKhggte1S6iYP4E0WZWTaI/8hZmxCXt2J1R8pyBVw+wmGnk lK5l8GcCQKHqZ9y3ecwuckIC3KgMuhnvGiqMPbBppai5gsLab47lCjzy5+s2nUe9b1S4 88gQ==; 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=1775619392; x=1776224192; 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=uff+TdcY/Nhu+JI2HDDKA3IabruJVxYTdOi16NU2Lwg=; b=RzBibbjixtgAQ3+60lLllWIFcr7R8Gqwjiqt0v1WL+zxaOO/o0YSIf2cSLidbw7pUA vluNlo5JM83F+LF6u4ZqJL3xOClZW0vY9EGcMuLXNtMrTDEwdHSYWsi4kMI2FlXXNaJL 8JTgyg+QUS7jLPAl3gr3BymYj2G+3wkzWp6Kau+5RxvjfMup/Nfz/qcZsy0Xtgo4zy/X 3cIcg6R2hkcsUXKSG3eYFtjWDqcCKyqxglS2w5eTlv5r1GBXEGP6/Ug6rn8Qh0jQLiRB NiIROGfqzqH7lwpQJsNNX2saYAJpScQ5CJq28KzI95VqDLXz93MVEjkeIQh3k8W9ALpj tcjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775619392; x=1776224192; 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=uff+TdcY/Nhu+JI2HDDKA3IabruJVxYTdOi16NU2Lwg=; b=gaZKFaVM54kfqN1ESKFBZjKDZn9keV5ZQLQo2IXTtpONQ3xSQgQwnascRMf4zoSrNr NmpKyFbEVfVSJSt315aahOHiY2WN4Kk0kESt8I/OGlpMBZxKcE0E+55pn0Q89RfDPfBc Y3fBwxouaOKHLIJiWI4bVoBXU2W1a0dvGBIuwTsTVSPd9HfgUcD2K0mghYxZv+kg2FRN qVVuzN+dDNiGZByJ+tdVzTkwCb1w1r+KS1kDjqtOtV3XOazN4POOosBQq7ZB+X5ue5UC nPJfhKMOrJi8n2oa60ciTEyc4jdakGkREu2679kNYrohxCphCBL0bULNGj9Japs0hPms vf5A== X-Forwarded-Encrypted: i=1; AJvYcCWYOsOYuSr+bsxpYkoeq4V1x/3SACYOpsatCAo167XktlE6xQ7rwQxsWozWNcQ7bX9s1vqJYGIlpbEKAvcS@lists.postgresql.org X-Gm-Message-State: AOJu0YwLasQubC4NwIQifDwKpED1eqq0vhO9xMZtrWM6OES5Wv5cXxN0 PwHECpAm0CuPBNfIVtkVV1H6BLoLgIyFV6+XSUzkeWJinjF5qYbm4o6vpH8612tD6Z0b4YIBwD4 cQVrXdWn9H6e7rksfWfkKaQKgYp3WD18= X-Gm-Gg: AeBDievGVPo55K1w2Z62SwkAe96av109GRXeJxzLtcShHuaPZmXBJaCCYp4x8/LrCaL 2u/pj55koeV1xL78Agf6DW5humrmgLC4h75OSwE9HbkeO7/xjFMJ0HUIaB1gq341cmXyv6XHzuE 1ymT9argJgpRMKg+a9O17KZLEFETy7p3+I21KaMuhVF9ZmBfLZlSa0xQLerQQcv/W09qpH+tlXb o5FQrBlwZrRzMQHLKTGMLa//1Q82zyBhIWCWXA2cTVlRLMadOe941KwygJ7seuwgdzrcvkBceN4 8ydYmjQOfhzYZsdQsxwWMLXGkb9x0Ts3GyJxx/CAWA== X-Received: by 2002:a05:6820:151e:b0:67d:eb9e:26ca with SMTP id 006d021491bc7-6821f487dd2mr10487554eaf.40.1775619392445; Tue, 07 Apr 2026 20:36:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Fujii Masao Date: Wed, 8 Apr 2026 12:36:19 +0900 X-Gm-Features: AQROBzBy5JVoZ_403uIk-9TGDF9RiJDxpTNwfzW_YE6VLBbF-UdfgiItMeBOcVA Message-ID: Subject: Re: Use SIGTERM instead of SIGUSR1 for slotsync worker to exit during promotion? To: Amit Kapila Cc: Nisha Moond , "Zhijie Hou (Fujitsu)" , shveta malik , PostgreSQL Hackers 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 Wed, Apr 8, 2026 at 11:39=E2=80=AFAM Fujii Masao = wrote: > > On Tue, Apr 7, 2026 at 12:48=E2=80=AFPM Amit Kapila wrote: > > I agree with this line of reasoning here or in general as well but > > personally I am a bit hesitant to back patch changes which are not > > mandatory. In this particular case, I don't see any problem with > > backpatching the part of code you want to backpatch, so I leave it to > > your judgement. > > Thanks for the comment! > > I decided to backpatch commit 1362bc33e02. Although pg_sync_replication_s= lots() > lacks retry logic in v17 and v18 and is therefore less likely to block > promotion, the issue still exists in those versions. > > Given that, it seemed worthwhile to backpatch the change and fix cases wh= ere > both the slotsync worker and pg_sync_replication_slots() can block promot= ion > when stuck in a wait. > > I've pushed and backpatched the patch. Thanks! The backpatch added PROCSIG_SLOTSYNC_MESSAGE in the middle of enum ProcSignalReason, which could break the ABI. I=E2=80=99m planning to move i= t to the end of the enum in v17 and v18. That seems to work for v18. However, in v17, NUM_PROCSIGNALS is defined as the last enum value: NUM_PROCSIGNALS /* Must be last! */ } ProcSignalReason; So simply moving PROCSIG_SLOTSYNC_MESSAGE to the end would change the meani= ng of NUM_PROCSIGNALS. One option might be to remove NUM_PROCSIGNALS from the enum, move PROCSIG_SLOTSYNC_MESSAGE to the end, and define it separately, e.g. #define NUM_PROCSIGNALS (PROCSIG_SLOTSYNC_MESSAGE + 1). Would that be acceptable without breaking the ABI? Thoughts? Regards, --=20 Fujii Masao