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 1rSqeA-00GJO0-2C for pgsql-hackers@arkaria.postgresql.org; Thu, 25 Jan 2024 03:43:22 +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 1rSqe8-00BaRg-Oq for pgsql-hackers@arkaria.postgresql.org; Thu, 25 Jan 2024 03:43:20 +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 1rSqe8-00BaRY-F6 for pgsql-hackers@lists.postgresql.org; Thu, 25 Jan 2024 03:43:20 +0000 Received: from mail-oa1-x2a.google.com ([2001:4860:4864:20::2a]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rSqe6-003EYE-4s for pgsql-hackers@postgresql.org; Thu, 25 Jan 2024 03:43:19 +0000 Received: by mail-oa1-x2a.google.com with SMTP id 586e51a60fabf-20451ecbb80so3207173fac.2 for ; Wed, 24 Jan 2024 19:43:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706154197; x=1706758997; darn=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=D1eMZAADfWr45yNrMf4tyz69XEg1bAUatiS2VSw95wY=; b=KXxhdqHMCnOGwJr54XsqiaDDsoYGxwJYaKZN5/Q4Hi9D02Vpz98RsUEDj644h+iuus itxUObrvFfYU3+FvYHmKYPVFMpzd4eIo6993ewyvO5m1tVaIejIbR++RwmgoLDZMYnDn Xwb+wOAgGDt9Veh7/IGrbRZuDPc06OTYSeKdLcy3pQMW38722I+ueQaYoVsMiuaFrz8M HHmI+KTUuSPi7g8qc6HprqKii06fiu8u2bMaGo/P/aHyzB1TVw/FzZw0O7YYwmT3BRNO 0pXuF9kWmMNHYFoNdL2YYmDEQFMnOe12gjHoEprpXHzcztTt2OUvyruRYRysX5XlVTPh CC6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706154197; x=1706758997; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=D1eMZAADfWr45yNrMf4tyz69XEg1bAUatiS2VSw95wY=; b=VxxQiUOK2fAVqhDIFFZk2V+/NkvoNlDA+q7MsysnAZh0vTjuBxRdyhNqXtX0QhPOHY Rt2Xr15I+492hxetsHlmsJ5RuHxl9F3ylSDh1BuYA83ZSWUX5x2v+DZSFONwhpdZajPv bxtl1pL+yfCefBd67rdDAfcpZMp5eGrrP6mDjAtgFrtzhRGw7N83wEIv+c5YpU7XOxkj 8C5WS/yuyc7nvZ+VXPc3tY0IOpYb/7CpfGmFNMiL9HnI6X4x3FEu+cy9u7F93Xh0jSPD f/qNzka11vi9nMoFXg+IONUrXu5T9zP+Ta/wNMMLT40bl9ff8KfFbk/LLyELltXW/CJs PV8w== X-Gm-Message-State: AOJu0YwKp3bPRdcHxeRCPNGDqo78h6egVnTR9eMA3Qqx416NvMafeBWv 9WozuuT5WoBOR+IYRHRXbzlVOVZcHdtXZZKxYAIwm4GZOolY7HVTUNZ8rnC8BYsfQmQ5gTX6HL4 SiXMlzzwzi/duqSrpUtVTsoVaM6E= X-Google-Smtp-Source: AGHT+IHnanKszfZcm5iO1QvRN6rJgXpvbUV7jpU8VIwGBPy/UIQkab1wh8jElqt523y6iZUZmQFJVjiShnOtTeeqac0= X-Received: by 2002:a05:6870:7f02:b0:210:9892:c299 with SMTP id xa2-20020a0568707f0200b002109892c299mr253383oab.100.1706154197314; Wed, 24 Jan 2024 19:43:17 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Amit Kapila Date: Thu, 25 Jan 2024 09:13:05 +0530 Message-ID: Subject: Re: Synchronizing slots from primary to standby To: shveta malik Cc: Bertrand Drouvot , Masahiko Sawada , "Zhijie Hou (Fujitsu)" , Dilip Kumar , Peter Smith , Nisha Moond , "Hayato Kuroda (Fujitsu)" , Bharath Rupireddy , Peter Eisentraut , Bruce Momjian , Ashutosh Sharma , Andres Freund , pgsql-hackers , Ajin Cherian , Alvaro Herrera 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, Jan 24, 2024 at 5:17=E2=80=AFPM shveta malik wrote: > > PFA v67. Note that the GUC (enable_syncslot) name is unchanged. Once > we have final agreement on the name, we can make the change in the > next version. > > Changes in v67 are: > > 1) Addressed comments by Peter given in [1]. > 2) Addressed comments by Swada-San given in [2]. > 3) Removed syncing 'failover' on standby from remote_slot. The > 'failover' field will be false for synced slots. Since we do not > support sync to cascading standbys yet, thus failover=3Dtrue was > misleading and unused there. > But what will happen after the standby is promoted? After promotion, ideally, it should have failover enabled, so that the slots can be synced. Also, note that corresponding subscriptions still have the failover flag enabled. I think we should copy the 'failover' option for the synced slots. --=20 With Regards, Amit Kapila.