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 1r1RFG-00BBPa-C4 for pgsql-bugs@arkaria.postgresql.org; Fri, 10 Nov 2023 13:08:22 +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 1r1RFE-003apg-LR for pgsql-bugs@arkaria.postgresql.org; Fri, 10 Nov 2023 13:08:20 +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 1r1RFE-003apY-Ai for pgsql-bugs@lists.postgresql.org; Fri, 10 Nov 2023 13:08:20 +0000 Received: from lana.depesz.com ([88.198.49.178] helo=depesz.com) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1r1RF8-005k00-2N for pgsql-bugs@lists.postgresql.org; Fri, 10 Nov 2023 13:08:19 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=depesz.com; s=20170201; h=In-Reply-To:Content-Transfer-Encoding:Content-Type:MIME-Version :References:Reply-To:Message-ID:Subject:To:Sender:From:Date:Cc:Content-ID: Content-Description; bh=nL3hragZBtUJ3Jg+/77ke243/V1IXomWJUEzoOP6u38=; b=S4Xcq wQbbY5+ZHGHw5G8erMN4XGQYOOycUXfwAyJYarwlVnx7yjVOLQWakgjpfh1rju6rl0kZZFI10rvua c4N8CSFRRcW6fWSiSLkHgzqdNlEhyItarFOZ5hCLeHl7D1bmfVQ/FlmHx1uPunfP4be2XcpvjYGYt Fi2bUmcI8k90=; Received: from depesz by depesz.com with local (Exim 4.94.2) (envelope-from ) id 1r1RF4-00BHYC-PB; Fri, 10 Nov 2023 14:08:10 +0100 Date: Fri, 10 Nov 2023 14:08:10 +0100 From: hubert depesz lubaczewski Sender: depesz@depesz.com To: Tomas Vondra , Amit Kapila , Kyotaro Horiguchi , kuroda.hayato@fujitsu.com, pgsql-bugs@lists.postgresql.org Subject: Re: Logical replication is missing block of rows when sending initial sync? Message-ID: Reply-To: depesz@depesz.com References: <20231102.101713.170587046871054404.horikyota.ntt@gmail.com> <2a638962-7a62-abd6-d9a4-3c322ec2a06d@enterprisedb.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Fri, Nov 10, 2023 at 12:44:17PM +0100, hubert depesz lubaczewski wrote: > > I think it'd be interesting to look at the WAL using pg_waldump, and see > > how it relates to the LSN used for the tablesync slot. > > well, I can try to dump, and show data, but it will most likely be > a lot. Are you more interested in looking into wal around the second > where data was inserted, or when table was added to publication? I tried to find it based on relfilenode of assignments table, and ctid, but I can't find it in waldump :( I'm probably doing something wrong, or basing on wrong assumptions, but I got 33GB of wal, dumped it all, found relfilenode (41441) and grepped for this, and block number (ctid │ (24192,1), so i assumed block 24191, 24192, or 24193 - nothing like this exists in wal dump. Best regards, depesz