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 1nWcf5-00044e-7U for pgsql-bugs@arkaria.postgresql.org; Tue, 22 Mar 2022 11:26:51 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nWcf4-0003SG-2a for pgsql-bugs@arkaria.postgresql.org; Tue, 22 Mar 2022 11:26:50 +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 1nWcf3-0003S7-Pa for pgsql-bugs@lists.postgresql.org; Tue, 22 Mar 2022 11:26:49 +0000 Received: from lana.depesz.com ([88.198.49.178] helo=depesz.com) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nWcf1-0002b5-Mn for pgsql-bugs@postgresql.org; Tue, 22 Mar 2022 11:26:49 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=depesz.com; s=20170201; h=In-Reply-To:Content-Type:MIME-Version:References:Reply-To: Message-ID:Subject:Cc:To:Sender:From:Date:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=wi+8DnIP4NgogioRN8wt9RKznXp5LFPch1XpFCMxv9Q=; b=K72gzJWQ/tLkXSB93ioTf2XnBs G8LriZ1uJs8uYCZoSqi/NzN2bLr7kEgBTfrQzUkLa5fdgOFYEtf7KaB1Ws0ttif46BiL5Dlpb/mOb 3XPTwwYSYtPbKaXszrnsplSKO1rexrKV5Wmbj1SJSlnWwaw7jmoABcsX8ASZdVyOw4ms=; Received: from lana.depesz.com ([88.198.49.178] helo=depesz.com) by depesz.com with esmtpa (Exim 4.92) (envelope-from ) id 1nWcf0-0005mG-6e; Tue, 22 Mar 2022 12:26:46 +0100 Date: Tue, 22 Mar 2022 12:26:46 +0100 From: hubert depesz lubaczewski Sender: depesz@depesz.com To: vignesh C Cc: pgsql-bugs mailing list Subject: Re: Logical replication stops dropping used initial-sync replication slots Message-ID: <20220322112646.GA14817@depesz.com> Reply-To: depesz@depesz.com References: <20220317142426.GA727@depesz.com> <20220318122758.GA25022@depesz.com> <20220321144341.GA27089@depesz.com> <20220322034847.GA15952@depesz.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, Mar 22, 2022 at 12:32:41PM +0530, vignesh C wrote: > > That wouldn't do me any good. The server I'm trying to upgrade now is > > test bench to make sure that I can upgrade using logical replication *at > > all*. > > Once I will have verified that I can, I have couple hundred servers to > > upgrade, that will have concurrent access all the time. > Is it possible to get a reproducible test or a script for this problem? Well, given that we're talking about 38GB database with 60k tables i find that unlikely. But I'll try if I can figure out a way to replicate the problem with something that is shareable. depesz