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 1vvYlo-007rI3-2r for pgsql-hackers@arkaria.postgresql.org; Thu, 26 Feb 2026 10:39:01 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vvYlm-00BpyF-2i for pgsql-hackers@arkaria.postgresql.org; Thu, 26 Feb 2026 10:38:58 +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 1vvYlm-00Bpy0-1R for pgsql-hackers@lists.postgresql.org; Thu, 26 Feb 2026 10:38:58 +0000 Received: from mail-vs1-xe30.google.com ([2607:f8b0:4864:20::e30]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1vvYli-00000001HOD-3VY6 for pgsql-hackers@postgresql.org; Thu, 26 Feb 2026 10:38:57 +0000 Received: by mail-vs1-xe30.google.com with SMTP id ada2fe7eead31-5ff09bb6271so473802137.0 for ; Thu, 26 Feb 2026 02:38:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1772102335; cv=none; d=google.com; s=arc-20240605; b=P8wNJ+lUlVCoCs889+UT1R7vth6MFanPZAUlEkQtUSY8OvfhegJQrxyhUjn5QCDHNk AHYf5ca+YkeV5r7usl3HifUKdtZXwe4LC5t9FVVJhv67gCZVQB1IoAD2VDw7AZ8Q321f ifKo5hFv1CWaFVl7giCfZgTpGyaQMaUKpNjudHjQscz8m8rO6OKhm+gFN1zsyf/MTJq4 KwIl17lx8aj7U+AX8AmiVa+vt40rj1bqjMDIRsjBOqQwu5Ab/COp23t0+U1tnOH3Irnp EjQWSHdV0qmvRP6BlvXKO5C9EZ6xCswsGfg9wU9hqY3ydzfwnAy9yGPJKDIxgZnD+vmo rvHQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=UW+5PtrQoaa8wo0cd6R/XAH+UxgBYwlFbWZZuIeCg1c=; fh=hXK85jmtPZDlpExK6jAYkwWy0x0Ljc3zW4W5J0c2jzw=; b=BDsCOK0NFGa9APoy7JiwWN4F8sR3H0hVyofEl/W/IHhB0nRIjodkfABeel3B/Jk+Uh WVhcI+refg2Feva29Ixdq0FpPmW1QCvzVqbrDu25fb0YG0xbGR5S20RP7w7a7RkNtmK7 1H80o6bZJ+oIvilWG07CLl1MZ8lv16Tp1ROmj+/stNLd+ZNgw19YIaVYJXAbertB6uYN J90r/bdvHuZ6pTeKxLMhKBb1UCvJalBMo9Ej1yuhlanClSGQjhAWOScu830vD4DYAuHF 30PERQO+RagsmTccDJ0V/4EX1HOPpl8z1diGFZgl3m5QagScSnhQK/AK0Ha7floAaI/N gLig==; darn=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=20230601; t=1772102335; x=1772707135; darn=postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=UW+5PtrQoaa8wo0cd6R/XAH+UxgBYwlFbWZZuIeCg1c=; b=CkuJMws1QOtEKZ80jVnmJPO8Cv7uHc9PhqB4uo8v6EOeKkKIHc7XDtVbfoS9LU8iMs Zq+OZSEQIZUr8jrZMNKTMLSH4EBdtWoEpm7m0OvxYnr+9KSTDpXN5IWVuzP5EbCqFvs5 wGWIACShgMGpeQGTqk7jlBsRWCjKLyyNkBYYffxamdGBliWd8WWtSVTNojH1u8Kzu8AH TgfSfiactdyxMJVapVLnybdL3+WZ0wX7MLAb1U7gWVWHnQow3uKyUYxXqyorBuCbNjwZ yAUMX+aiUUHSuYcP6MpHSfOuIsjdCH2HWUFVR2Pgz5btjKpctbDoJPInsaS/YRc0yYSy 7gOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772102335; x=1772707135; h=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=UW+5PtrQoaa8wo0cd6R/XAH+UxgBYwlFbWZZuIeCg1c=; b=UTU60+W25BVGg2SgSuAw0dfuyDNm+zT9EnwSs6bxMIIM0CqoAbMPteqpcoAookaD6x gEQ2NRtf15/HK7BbscQfJL6rk56g16/PFHy8Z7Y+KrEOK8A5X7p9nDWwf0WYB2/e+D2/ bKct0tB7qa8shMXvtECIdItkr0XcDYwixxrB2v+87E+LmaeB583PEwcLyEszY33qmWs6 Uh9coERQkHaKW1nRf2mpI0tJ+oSgSxrVEKEA0vcWzhzSnwfYdHf2k5rbcYj/qPahZ1eu BSNPtiOHS4qVkJvnjzaIjcVwDs9pHxQL2DIFZTtdwZ3YLrCV+5Q8ALSIEMChPFmrj/KW t2Gg== X-Forwarded-Encrypted: i=1; AJvYcCWq6t/TaXezI+ASdKdMoqVVPZSoyzXYEjlLOcWnqnNgjt1ukBmSLvpcNDC4Wo7R/FlECriiAHaardOQcG+J@postgresql.org X-Gm-Message-State: AOJu0YwmW5WVrPMPNOeNAioSIQPG2xk0JHt2gMCVnwY2S9OxS3HfuaON +lc8T6NbQdOsHinKATzoxbElMa4v3a7zmK0YrnKChE5/zz5l+fZqa7c9ADOrx18T9rzEkhH65y1 8qFqhqAMXwHrIuOVTMfcwlWcN2/ipkO8= X-Gm-Gg: ATEYQzzGcUPG5k0uEoto8ENyk1naSQ4nlVVbCm09Z74mxsdt8DDV1m8daFLutRiZ5Aq 5fJDx4kJk+yL6B4OYzDvOcTax0YO79x954Nw8iIo34bDX2UmJDwYsfEt+D++H1fSJnbVkqOpDdc NBx6YX74rdQQzOXwbedTCUDsk1HL1KTpHC3lGfq3lNNSeg5PFatncge2YQ7QeIEY2Bm8+4Hua8/ 1Je+i8CeItAfiJnPjXKlmssjl32EOythvQlvKUQ+tIfMsnUkxd49r6isue3sb20ix1HaJ8uqz9o 9X/hjLU= X-Received: by 2002:a05:6102:3587:b0:5f8:e41e:e5cc with SMTP id ada2fe7eead31-5ff1ce60630mr805672137.9.1772102335210; Thu, 26 Feb 2026 02:38:55 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: SATYANARAYANA NARLAPURAM Date: Thu, 26 Feb 2026 02:38:44 -0800 X-Gm-Features: AaiRm50ansTOlibHwt2MqLeNetz3VD_akSKS-e0VRPVwUkDr0wdYZL0xYdT87RU Message-ID: Subject: Re: synchronized_standby_slots behavior inconsistent with quorum-based synchronous replication To: Alexander Kukushkin Cc: shveta malik , Ashutosh Sharma , Amit Kapila , PostgreSQL-development , PostgreSQL Hackers Content-Type: multipart/alternative; boundary="0000000000003228b9064bb7ba02" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000003228b9064bb7ba02 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Alexnader, On Thu, Feb 26, 2026 at 1:29=E2=80=AFAM Alexander Kukushkin wrote: > Hi, > > On Thu, 26 Feb 2026 at 09:45, shveta malik wrote= : > >> >> As suggested in [1], IMO, it is a reasonably good idea for >> 'synchronized_standby_slots' to DEFAULT to the value of >> 'synchronous_standby_names'. That way, even if the user missed to >> configure 'synchronized_standby_slots' explicitly, we would still have >> reasonable protection in place. > > > Hmm. > synchronous_standby_names contains application_names, > while synchronized_standby_slots contains names of physical replication > slots. > These are two different things, and in fact sync replication doesn't even > require to use replication slots. > What is worse, even when all standbys use physical replication slots ther= e > is no guarantee that values in synchronous_standby_names will match > physical slot names > That's right, thanks for reminding me. I am convinced that we can't use the defaults of synchronous_standby_names for synchronized_standby_slots. What do you think about the rest of the proposal? Thanks, Satya --0000000000003228b9064bb7ba02 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Alexnader,

On Thu= , Feb 26, 2026 at 1:29=E2=80=AFAM Alexander Kukushkin <cyberdemn@gmail.com> wrote:
Hi,
On Thu, 2= 6 Feb 2026 at 09:45, shveta malik <shveta.malik@gmail.com> wrote:

As suggested in [1], IMO, it is a reasonably good idea for
'synchronized_standby_slots' to DEFAULT to the value of
'synchronous_standby_names'. That way, even if the user missed to configure 'synchronized_standby_slots' explicitly, we would still h= ave
reasonable protection in place.

Hmm.
synchronous_standby_n= ames contains application_names, while=C2=A0synchronized_standby_slots contains= =20 names of physical replication slots.
These = are two different things, and in fact sync replication doesn't even req= uire to use replication slots.
What is wors= e, even when all standbys use physical replication slots there is no guaran= tee that values in=C2=A0synchronous_standby_names will match physical slot = names

That's ri= ght, thanks for reminding me. I am convinced that we can't use the defa= ults of synchronous_standby_names for synchronized_standby_slots. What do y= ou think about the rest of the proposal?

Thanks,
Satya
--0000000000003228b9064bb7ba02--