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 1mxGDR-0007KW-7X for pgsql-hackers@arkaria.postgresql.org; Tue, 14 Dec 2021 22:24:09 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mxGDP-0003eN-VG for pgsql-hackers@arkaria.postgresql.org; Tue, 14 Dec 2021 22:24:07 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mxGDP-0003d1-LL for pgsql-hackers@lists.postgresql.org; Tue, 14 Dec 2021 22:24:07 +0000 Received: from out1-smtp.messagingengine.com ([66.111.4.25]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mxGDN-0006eO-8v for pgsql-hackers@postgresql.org; Tue, 14 Dec 2021 22:24:06 +0000 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id D51D05C02CE; Tue, 14 Dec 2021 17:24:03 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Tue, 14 Dec 2021 17:24:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=VpdTGa/p4tF2tmr4NrELEYVZB/0QbhbDfM4r6xNNA bs=; b=e0aYXbOJSjXMLXc8grcPVJYsAgD4H0MN4D8vJYfopWbWwvtRe7hBSeg3H i0KYcHBFhg/ftLvVEyjqe+QWOtvQewQFyFaI3PI8RbSEyk0vTHpNKPNwiDIATX4S YUg3BdAxhP8E3kfXQG5urZUihdxgSxkKB99hrUBzk3Keq3VT9rEgyAurnhL1n2Ma LilLVDbr/NaiGZ9dj0w0LdSQd3XNqXXGBMBgwfOf3n0/tXCMGLvG60CxKmTHO0b7 Rr8ebJKmeSroNUlWixMLp83vCESq1bltUI1+cH/dge/4GBZyLIEDWlojaf0hdDqz 8In0H95+sgM8SJE2hnRXl/O2d8tjQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrledtgdduieduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefkffggfgfuvfhfhfgjtgfgsehtje ertddtfeejnecuhfhrohhmpefrvghtvghrucfgihhsvghnthhrrghuthcuoehpvghtvghr rdgvihhsvghnthhrrghuthesvghnthgvrhhprhhishgvuggsrdgtohhmqeenucggtffrrg htthgvrhhnpeefjeegheetuefhveevudelueeftdejteeiffetvdduhfdtieefgfeutedt veeggfenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hpvghtvghrrdgvihhsvghnthhrrghuthesvghnthgvrhhprhhishgvuggsrdgtohhm X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 14 Dec 2021 17:24:03 -0500 (EST) Message-ID: <0ee342de-4422-809f-8e4d-fbd99370bed9@enterprisedb.com> Date: Tue, 14 Dec 2021 23:24:02 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Subject: Re: Synchronizing slots from primary to standby Content-Language: en-US To: Bharath Rupireddy Cc: pgsql-hackers References: <514f6f2f-6833-4539-39f1-96cd1e011f23@enterprisedb.com> From: Peter Eisentraut In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 28.11.21 07:52, Bharath Rupireddy wrote: > 1) Instead of a new LIST_SLOT command, can't we use > READ_REPLICATION_SLOT (slight modifications needs to be done to make > it support logical replication slots and to get more information from > the subscriber). I looked at that but didn't see an obvious way to consolidate them. This is something we could look at again later. > 2) How frequently the new bg worker is going to sync the slot info? > How can it ensure that the latest information exists say when the > subscriber is down/crashed before it picks up the latest slot > information? The interval is currently hardcoded, but could be a configuration setting. In the v2 patch, there is a new setting that orders physical replication before logical so that the logical subscribers cannot get ahead of the physical standby. > 3) Instead of the subscriber pulling the slot info, why can't the > publisher (via the walsender or a new bg worker maybe?) push the > latest slot info? I'm not sure we want to add more functionality to > the walsender, if yes, isn't it going to be much simpler? This sounds like the failover slot feature, which was rejected.