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 1sGyJA-001ZqD-W6 for pgsql-hackers@arkaria.postgresql.org; Tue, 11 Jun 2024 10:00:53 +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 1sGyJ9-004moS-7h for pgsql-hackers@arkaria.postgresql.org; Tue, 11 Jun 2024 10:00:52 +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.94.2) (envelope-from ) id 1sGyJ8-004moK-Tc for pgsql-hackers@lists.postgresql.org; Tue, 11 Jun 2024 10:00:51 +0000 Received: from mail-wm1-x333.google.com ([2a00:1450:4864:20::333]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sGyJ6-0015Ji-Vm for pgsql-hackers@postgresql.org; Tue, 11 Jun 2024 10:00:51 +0000 Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-421a1b834acso17039685e9.3 for ; Tue, 11 Jun 2024 03:00:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718100048; x=1718704848; darn=postgresql.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=aIrhOIhLfJ4zXhev1+q4yExjFE0p9uqcHF7+VnfPfQ8=; b=L2rhlusjxEpSohDCvtvPrEVRTX3f1vEN1A/Angq66trFXSBoCrJoBooWrPLF1X0upB GosBTxUkdawST9i/fsuBHadMUbRQ+CfnG7JHI4eLpZLI8wT4EXcWqLbgR8yiFV8gJI1F E9VL97a+e+ENkh3lFFLf1FnLXcj4Esc54LeaySphv0VWHmVn0mVZqF9uU5AipRyfIe7t rtqMgELWbK/oq9/7gviY9VDHekOS9p6v0KriXh/he6P+QOJlRlNnTRkwe6VVDzSI45wb /f12zqz5UH/IJ3RJo7ehA0saUsJKrpdnvV0xTD/xDoIGpO9LF/mGl9tq2lEJDHeI/C/y rcXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718100048; x=1718704848; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=aIrhOIhLfJ4zXhev1+q4yExjFE0p9uqcHF7+VnfPfQ8=; b=dmABGKk5YBq6Pei8MzBm9ORi+CGkx9as3SHoIZLyWMT4CrGj29kzYXwWfJITRtN/j+ 0YaBoi9ad5f9moYfPrOLZOZjlKzpHNkP3TBAhLvPZSfYZHgE64m/LQARyvzNaTKFnxjr RHEF9bWUWb7rizdP1ffkYtMhFrTgAVyCW6Knejyy9eCamdI/jndbhDq16M+PYhAYYY7e X6xMpyi5/J7PusrfvBvCn0FkxnrOA4StkoHI3bZU/7rb/e0ovwnYadu98e0UkqbtbPb8 G2Vj+Y7T/hMvJ5gCdL2ulZ0eK7Mmze4y9LCtmYcMDbebmYyKKCDihx8U+OT1aFnVnLur EUoQ== X-Forwarded-Encrypted: i=1; AJvYcCUT0CSFBoU+zV4WvcnvG62BK/Y99NBBQHnIlPUENfFcJf3GAMiWPz1mTcv5933dO8xC3Nw7OraLpgnJ03FgJXEW9BZskcVHZD4Y0oQb X-Gm-Message-State: AOJu0YztDOI8e67cdhXcRolVI88EalWxrAiX7ZBmwBJFhEllKGcfktPs LecKkly0qszr8aFVeE52XCAZOMyHvNe1EtmqhlbWU8ehZ6B0NoCj2i65WQ== X-Google-Smtp-Source: AGHT+IFKK1Nu3Kh8SGrrE3ggh+69+lQ4WuupmFs9NVv6Ry+30RLZzkx3jJvep9TLL5Ji9+C86W9YzA== X-Received: by 2002:a05:600c:c0f:b0:422:370a:ca57 with SMTP id 5b1f17b1804b1-422370acd38mr19416155e9.36.1718100047840; Tue, 11 Jun 2024 03:00:47 -0700 (PDT) Received: from ip-10-97-1-34.eu-west-3.compute.internal (ec2-15-236-134-5.eu-west-3.compute.amazonaws.com. [15.236.134.5]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-421ff76799esm49827535e9.32.2024.06.11.03.00.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 11 Jun 2024 03:00:47 -0700 (PDT) Date: Tue, 11 Jun 2024 10:00:46 +0000 From: Bertrand Drouvot To: Nathan Bossart Cc: John H , pgsql-hackers@postgresql.org Subject: Re: Allow logical failover slots to wait on synchronous replication Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi, On Mon, Jun 10, 2024 at 09:25:10PM -0500, Nathan Bossart wrote: > On Mon, Jun 10, 2024 at 03:51:05PM -0700, John H wrote: > > The existing 'standby_slot_names' isn't great for users who are running > > clusters with quorum-based synchronous replicas. For instance, if > > the user has synchronous_standby_names = 'ANY 3 (A,B,C,D,E)' it's a > > bit tedious to have to reconfigure the standby_slot_names to set it to > > the most updated 3 sync replicas whenever different sync replicas start > > lagging. In the event that both GUCs are set, 'standby_slot_names' takes > > precedence. > > Hm. IIUC you'd essentially need to set standby_slot_names to "A,B,C,D,E" > to get the desired behavior today. That might ordinarily be okay, but it > could cause logical replication to be held back unnecessarily if one of the > replicas falls behind for whatever reason. A way to tie standby_slot_names > to synchronous replication instead does seem like it would be useful in > this case. FWIW, I have the same understanding and also think your proposal would be useful in this case. Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com