Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mAWZp-0008PP-Ml for pgsql-hackers@arkaria.postgresql.org; Mon, 02 Aug 2021 11:57:49 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mAWZm-0006MS-El for pgsql-hackers@arkaria.postgresql.org; Mon, 02 Aug 2021 11:57:46 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mAWZl-0006MK-Tc for pgsql-hackers@lists.postgresql.org; Mon, 02 Aug 2021 11:57:45 +0000 Received: from mail-wr1-x42d.google.com ([2a00:1450:4864:20::42d]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1mAWZh-0006Wb-BZ for pgsql-hackers@lists.postgresql.org; Mon, 02 Aug 2021 11:57:44 +0000 Received: by mail-wr1-x42d.google.com with SMTP id h13so7691996wrp.1 for ; Mon, 02 Aug 2021 04:57:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aiven.io; s=google; h=from:to:cc:subject:date:message-id:organization:in-reply-to :references:mime-version:content-transfer-encoding; bh=fsnWDIK+Wqlhp/2D9kcjnmTwmyuZ83TFASSOF+5YKM4=; b=NS9wJNzsEFAWDFWHoje9zWne0/Nbb8uYFY9FMwiwr9fwSUJFc3Y0VExycVwAzalWpQ gTP5F7tpGi6ZHyxWueNqtoFNIzMfUKDdj5d2DBKnurJJn60GcPgV9dDASimxkITNTwXC AaBmaXUdsV+u/nnJOOb/vHxByXXh+9cFgPrrw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :in-reply-to:references:mime-version:content-transfer-encoding; bh=fsnWDIK+Wqlhp/2D9kcjnmTwmyuZ83TFASSOF+5YKM4=; b=DdTVZYJ//KfacsBQpf0XoML9EnwSM7skFSY2sVjVEPUjIFp1hoIV5ssY46FX6Q/ccq dj/d/5J/BvdZHfancOECn2CNov9T+61C066PCdEKyaqNN+qlr6OzTxGKIUUJC9s06XSx H6H+jkbwG5YfgztZc8GnFkZeDt6yexaEQnoJW/a+xS76JdnhVI//lhFAagBV1vI1oolh l84vcumJgKqFPOFyUlAsKq9ukdd11DqSxK8gsP+GsU9muJoHnp/DxGbfcpBN9ketK59i yXMWvE5hgs0gWC0HYQN7yspyerm6qecA0AnZ64DfPaEvpNAcl2y/WEqdjB0lFcrkmMe4 OrxA== X-Gm-Message-State: AOAM533tPmHW0m0fU2TLs4Ew0tFNEDKviB4Jxk0DMLwaXvVxVv5Ic06/ O3XxWchcPzgh+CpqjcMtTcNAGg== X-Google-Smtp-Source: ABdhPJyGOTZfpgyolBpR47yIacRfKMLmL/vsQe8Z1AXPPb1hu0p1RCkXYuCn03avfqs6k7/dh/Eo3Q== X-Received: by 2002:a5d:5111:: with SMTP id s17mr16862880wrt.227.1627905459104; Mon, 02 Aug 2021 04:57:39 -0700 (PDT) Received: from aivenronan.localnet (static-176-158-121-96.ftth.abo.bbox.fr. [176.158.121.96]) by smtp.gmail.com with ESMTPSA id l9sm10930901wro.92.2021.08.02.04.57.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Aug 2021 04:57:38 -0700 (PDT) From: Ronan Dunklau To: Ibrar Ahmed , Amit Khandekar , pgsql-hackers@lists.postgresql.org Cc: Andres Freund , fabriziomello@gmail.com, Alvaro Herrera , tushar , "[pgdg] Robert Haas" , Rahila Syed , pgsql-hackers , "Drouvot, Bertrand" Subject: Re: Minimal logical decoding on standbys Date: Mon, 02 Aug 2021 13:57:22 +0200 Message-ID: <1655255.DiLJNMXF8A@aivenronan> Organization: aiven In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Le mardi 27 juillet 2021, 09:23:48 CEST Drouvot, Bertrand a =E9crit : > Thanks for the warning, rebase done and new v21 version attached. >=20 > Bertrand Hello, I've taken a look at this patch, and it looks like you adressed every prior= =20 remark, including the race condition Andres was worried about. As for the basics: make check-world and make installcheck-world pass.=20 I think the beahviour when dropping a database on the primary should be=20 documented, and proper procedures for handling it correctly should be=20 suggested. Something along the lines of: "If a database is dropped on the primary server, the logical replication sl= ot=20 on the standby will be dropped as well. This means that you should ensure t= hat=20 the client usually connected to this slot has had the opportunity to stream= =20 the latest changes before the database is dropped." As for the patches themselves, I only have two small comments to make. In patch 0002, in InvalidateConflictingLogicalReplicationSlots, I don't see= the=20 need to check for an InvalidOid since we already check the SlotIsLogical: + /* We are only dealing with *logical* slot conflicts. */ + if (!SlotIsLogical(s)) + continue; + + /* not our database and we don't want all the database,=20 skip */ + if ((s->data.database !=3D InvalidOid && s->data.database=20 !=3D dboid) && TransactionIdIsValid(xid)) + continue; In patch 0004, small typo in the test file: +################################################## +# Test standby promotion and logical decoding bheavior +# after the standby gets promoted. +################################################## Thank you for working on this ! Regards, =2D-=20 Ronan Dunklau