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 1w7AUy-0051eu-1O for pgsql-hackers@arkaria.postgresql.org; Mon, 30 Mar 2026 11:09: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 1w7AUw-002gIb-2l for pgsql-hackers@arkaria.postgresql.org; Mon, 30 Mar 2026 11:09: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 1w7AUw-002gIP-1p for pgsql-hackers@lists.postgresql.org; Mon, 30 Mar 2026 11:09:34 +0000 Received: from mail-oi1-x22e.google.com ([2607:f8b0:4864:20::22e]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1w7AUv-00000001n4Z-19Q6 for pgsql-hackers@lists.postgresql.org; Mon, 30 Mar 2026 11:09:34 +0000 Received: by mail-oi1-x22e.google.com with SMTP id 5614622812f47-464bba3a9easo2675018b6e.0 for ; Mon, 30 Mar 2026 04:09:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1774868972; cv=none; d=google.com; s=arc-20240605; b=ADN2NfrY0X1kLIHcarD1Yg2doMtlr9wdvaqAkyFOiHd/0JoSL6G3owSK/cJJqYpTIZ tLZrMhGBAx7rt6vqMDmTzJR3R/4nR0XuZOBPQzWCDHx1MoNNJXuLuBpFsiSIZwwUlFQi T8NBreGjyFr/9O1O+ZJOTZ3qByvHBTMuXLvXSwYEbmHwLcgY2UJp1V4BasYaZqhj+/Ha HKG46mR9kvRB4tOQQ/jVvJjfcBDOKmUKRxl++RiEV8cI/EuKyp+8M4cNjKVRaJZ7PwP5 29ootfx59gamEv8WMi46dGBsQAj2RkualvO879s5+V2lQ2SmBlaHf8P4mn3zWb38RtZ7 1GFg== 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=KWA5vvtUyRNfaeW73YEd8OCL0qERnii6fa3CmJsORkc=; fh=5WoMMxF+J9WyJmtGQcPhqJmPFqiFOGbbDiJXe8/BzWM=; b=X5yOcDc4lq+sLOyDhV/pNlFBuUq2uywjqFG92xnRsm+D2xk/5Pq1417ua8AbwRqck7 Lxmhb2DPw2kYuAuKbTaBX0SYmczLBg2+C7OzEONNm/MKJGbfPkOE7yFJBI4U7lT9gSOo vLsAmPKBS5zQSsT8ijDBgp7bRhgK0OFOCsqQNHmVWUcUNrRCcvxb19009KO3Sy9W+bPZ MNFzvT3243lXsLNAJwjIAxKJH7z6troEukw0JUowsCj4QCpkU3cwtpkRMOSUQMShLynl TE+BliGUDfvHlMb8xqtZF6HMCwAQvkkK2ZtUNAFOYNzaKZnrVExxPNayB8mfF0mXsKMG aqsA==; 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=1774868972; x=1775473772; 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=KWA5vvtUyRNfaeW73YEd8OCL0qERnii6fa3CmJsORkc=; b=tBjYn64xaOjha1E27rwBe+y17CTwDanR0EMT8R+liK+oI/Wvc6/TTzd8Y2Abhzf5ER Yci//vl9Gs7NIS3wamxzY7mutm4AhJhKXyqODpJCcI7vpY4eDphxuGzX3p7PSyLqAC3o zppfpNvjciMWu0a+Sh+rNCERqY7a0hzUarPdX6Au0c8TPPGUq/VGifJ+aP2ybjZIr+lv Zh6P1+fvN15/M6XdJ4g8an4wBeRtuFXI4/sH6n+ZSgPqwSgPAeoejZyQC5WHksdmU/XE ChcTCtlbx+CQJ5zp4yJbDteGm/6C8HRZlur9G9D//V3sWJKUKDxIQzTtaJZ2+625EPFi rxVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774868972; x=1775473772; 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=KWA5vvtUyRNfaeW73YEd8OCL0qERnii6fa3CmJsORkc=; b=FbYMw/8z640dToD+eGyz3U88Dv0Zubs2dRFdBksBCdIK4rhk1KFiruoNxjwB4Ke8FD TwpwwEINWFWv2EtK3ESz0wmzfysWQffd5+1/Lk0Wv6UyTKWx6IurUvKSeUWaFbA4A/og xdhZX30sp0I9DvQR1XUpl/YpEStRkVPxC+4tLQR/G5XXvwI9euG44MMpqU7FQ5rZRqHM 7JWPxoouOz4dVEtJOPM2CYhcwwQP6GF9Ntdh27WB8xjQCVrwJ3aH5kP0HOXWXY+vHiJ5 GgAuiTlow47hBNkUjOCzNKgfLXvogYsFy3NzrSfK+DJ+Uv3tnhku2Z6zHcn77bjzoMfl 4vTA== X-Forwarded-Encrypted: i=1; AJvYcCVuKBEOFhR9Erzz4D3pDrxlk7SaOuv+yVuVghP0lQXei6uqwxmdnAWIC/7+AVhLCAKIy/LGF/Z/VwVFYkLH@lists.postgresql.org X-Gm-Message-State: AOJu0Yy1a+zyH3XcRRVUd5AxQkRiEPDh+xFIX7PrY8IIUbEaeNFdzmCU cP4l60HSu477fd1WPP1vv1xcsvaaxXRtv7hEn+GEw/rfqnkX0w56YMso7qXnRK6ro2JlQtziVRM QYxzRkuEoXQFLGZ5cNA1zbMhOUoq8gjo= X-Gm-Gg: ATEYQzx+yo6Ull5aYSmYjIH+9433m7553G4hvD7PSvRvYR8IqizBpqOob2jMWeHuVtV 4VMKViyoPrTX/Q/rJNboWl+na3actYzjXfKOLHzqsMiQrAlhhCpFaclSU4VA9LNWqvyvFLfJu6f fmzH2VuzjTF1ijIP6ID6RAWBYeKCyr07sixRs5C+Ps79o0Xz+ILAszmCKzOm2V1vsoWeEfoR4b4 3HgEhVw4mr9YFIWSrm/oVmx3+3In8NSkCyraVmnzOYEHiylsUpgnOkyIW2yIpMxFcALJ+IN5/4G p5Wtems2F42SuRyeJRndbvWR17BCk+/0ckyOpv1S/g== X-Received: by 2002:a05:6820:290b:b0:67d:f759:8787 with SMTP id 006d021491bc7-67e18702ec0mr6854598eaf.46.1774868972537; Mon, 30 Mar 2026 04:09:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Fujii Masao Date: Mon, 30 Mar 2026 20:09:20 +0900 X-Gm-Features: AQROBzDIFVMa1x74iRIpw-4_1bLkwPfTUsBqvf2x8-TPvCAqLA47DxaoME-2CNo Message-ID: Subject: Re: Use SIGTERM instead of SIGUSR1 for slotsync worker to exit during promotion? To: Nisha Moond Cc: Amit Kapila , 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 Mon, Mar 30, 2026 at 1:18=E2=80=AFPM Nisha Moond wrote: > We were using the same log message in two places: > check_and_set_sync_info() and HandleSlotSyncMessage(). > I think =E2=80=9Cwill not start=E2=80=9D fits better in the first case, w= hile =E2=80=9Cwill > stop=E2=80=9D makes sense to keep in the second. Thanks for updating the patch! With the patch, in my testing, standby promotion always produces the following logs: LOG: replication slot synchronization worker will stop because promotion is triggered LOG: replication slot synchronization worker will not start because promotion was triggered It looks like the postmaster immediately restarts the slotsync worker after promotion terminates it, and that new worker then exits on seeing SlotSyncCtx->stopSignaled. IMO, always emitting both messages is a bit confusing. It would be nice to suppress the second one if possible. One idea would be to prevent the restart altogether. For example, ProcessSlotSyncMessage() could set SlotSyncCtx->last_start_time to a special value (like -1), and SlotSyncWorkerCanRestart() could return false (i.e., prevent postmater from starting up slotsync worker) when it sees that. Alternatively, SlotSyncWorkerCanRestart() could simply check SlotSyncCtx->stopSignaled. That said, as far as I remember correctly, postmaster is generally not supposed to touch shared memory (per the comments in postmaster.c), so I'm not sure this approach is acceptable. On the other hand, postmaster and the slotsync worker already rely on SlotSyncCtx->last_start_= time, so perhaps there's some precedent here. Regards, --=20 Fujii Masao