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 1mAaAF-0006vJ-Aq for pgsql-hackers@arkaria.postgresql.org; Mon, 02 Aug 2021 15:47:39 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mAaAE-0005bT-77 for pgsql-hackers@arkaria.postgresql.org; Mon, 02 Aug 2021 15:47:38 +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 1mAaAD-0005bK-UO for pgsql-hackers@lists.postgresql.org; Mon, 02 Aug 2021 15:47:37 +0000 Received: from mail-wr1-x436.google.com ([2a00:1450:4864:20::436]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1mAaA9-0008Jg-Du for pgsql-hackers@lists.postgresql.org; Mon, 02 Aug 2021 15:47:36 +0000 Received: by mail-wr1-x436.google.com with SMTP id h14so21981216wrx.10 for ; Mon, 02 Aug 2021 08:47:33 -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=HA2w+2e57ZveYnfZLTJgtAxOxXII1xkVwuIi8XH9hpc=; b=EQJjuClLdb0/9nUudB2dWQNUG/esEFIXlqP43EaRWLTzrODRXD/eLZ0ZwIFu+9+fhO TFQotQuBkg33idKLlk042wv2RRUhvVJEEhO/muSImTwBblGdufoZ7/zX6Zp//RkM0gV3 ZSuYzf8eSmz5+a3juY2BAGwGKd/ORmsz2hNTk= 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=HA2w+2e57ZveYnfZLTJgtAxOxXII1xkVwuIi8XH9hpc=; b=fCChLm5PZffwBYXRxWImgBWzIvkxNzyjb2NkPmxYPg65cJgIcBo/TnHJQhKv0S1dXz YaolQ1Ee2Leg+E11SmEUDwsPYkrVHxHBIaprWJD9zvuO37+Kn4bu7jfw4IBjrCaFAflJ aXt7oEbxHPZ8FV3kFTfBwvwNAQiojHsNY2jpoNXk6WZhJRZfb3JOri0WK6263YN60LL4 1VCfe8Kd9ixt68ioa9sq23I9dg5Oxi9MtA0/2QXdSIKE7hn2HbR52CzCIDMZb7PMMZXn bo5QUVk2p+rwAqofA6m6pJR5beWfyn0dDOst59fQi0UNuyVg9jDVLDGNmfuaZ52qUOBD g/5g== X-Gm-Message-State: AOAM531gcguRUWvGO7FrG59MghjhOFEPPWI9B7ojaff66HnWKgIoCEgU vBaK03VbFAHiltcAkCzjF8JMJQ== X-Google-Smtp-Source: ABdhPJxSMuksAhw+k+V6tj7U8BnZuegdG4KCYdGUEpUmK6P+6s+/48u97kNNQlziUx4RAvlRPqmgOw== X-Received: by 2002:adf:ee4e:: with SMTP id w14mr18579771wro.15.1627919251261; Mon, 02 Aug 2021 08:47:31 -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 x18sm11706186wrw.19.2021.08.02.08.47.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Aug 2021 08:47:30 -0700 (PDT) From: Ronan Dunklau To: Ibrar Ahmed , Amit Khandekar , pgsql-hackers@lists.postgresql.org, "Drouvot, Bertrand" Cc: Andres Freund , fabriziomello@gmail.com, Alvaro Herrera , tushar , "[pgdg] Robert Haas" , Rahila Syed , pgsql-hackers Subject: Re: Minimal logical decoding on standbys Date: Mon, 02 Aug 2021 17:47:14 +0200 Message-ID: <7574277.rk4qtukel5@aivenronan> Organization: aiven In-Reply-To: References: <1655255.DiLJNMXF8A@aivenronan> 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 lundi 2 ao=FBt 2021, 17:31:46 CEST Drouvot, Bertrand a =E9crit : > > I think the beahviour when dropping a database on the primary should be > > documented, and proper procedures for handling it correctly should be > > suggested. > >=20 > > Something along the lines of: > >=20 > > "If a database is dropped on the primary server, the logical replication > > slot on the standby will be dropped as well. This means that you should > > ensure that the client usually connected to this slot has had the > > opportunity to stream the latest changes before the database is dropped= =2E" >=20 > I am not sure we should highlight this as part of this patch. >=20 > I mean, the same would currently occur on a non standby if you drop a > database that has a replication slot linked to it. The way I see it, the main difference is that you drop an additional object= on=20 the standby, which doesn't exist and that you don't necessarily have any=20 knowledge of on the primary. As such, I thought it would be better to be=20 explicit about it to warn users of that possible case. Regards, =2D- Ronan Dunklau