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 1r0j8E-007Qjg-J3 for pgsql-bugs@arkaria.postgresql.org; Wed, 08 Nov 2023 14:02:11 +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 1r0j8D-003eKU-2T for pgsql-bugs@arkaria.postgresql.org; Wed, 08 Nov 2023 14:02:09 +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 1r0j8C-003eKJ-Od for pgsql-bugs@lists.postgresql.org; Wed, 08 Nov 2023 14:02:08 +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 1r0j8A-005MNk-K9 for pgsql-bugs@lists.postgresql.org; Wed, 08 Nov 2023 14:02:08 +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=4ZACqqX0aF95CiA8ldoPpUjUsCjFGqdPwfmQWHB/KiE=; b=aLtHg JKdQvntG03d2XKcBk/VVllOON3AWodJQF8ibSDdF0pH+zCeCDWJDAwruJnIbVgeuQLcMoGa86l+jb BCuGZrL0fhOYc870NnrHEwPrGVmuiAPXh3thEoZQdp1TGPc0SGbFKoGS351VSn0ii6TXWz/ICpkj7 XRCX0ElUBzjo=; Received: from depesz by depesz.com with local (Exim 4.94.2) (envelope-from ) id 1r0j86-00CUzl-Vv; Wed, 08 Nov 2023 15:02:03 +0100 Date: Wed, 8 Nov 2023 15:02:02 +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> 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 > OK. found another case (maybe two). OK, the other case is real. Different database. Same scenario. Errors (3 because we have 3 missing fkeys): #v+ ALTER TABLE ONLY c44s16539.assignment_overrides ADD CONSTRAINT fk_rails_58f8ee369b FOREIGN KEY (assignment_id) REFERENCES c44s16539.assignments(id); ERROR: insert or update on table "assignment_overrides" violates foreign key constraint "fk_rails_58f8ee369b" DETAIL: Key (assignment_id)=(248083) is not present in table "assignments". ALTER TABLE ONLY c44s16539.post_policies ADD CONSTRAINT fk_rails_cf2d119863 FOREIGN KEY (assignment_id) REFERENCES c44s16539.assignments(id); ERROR: insert or update on table "post_policies" violates foreign key constraint "fk_rails_cf2d119863" DETAIL: Key (assignment_id)=(248083) is not present in table "assignments". ALTER TABLE ONLY c44s16539.submissions ADD CONSTRAINT fk_rails_61cac0823d FOREIGN KEY (assignment_id) REFERENCES c44s16539.assignments(id); ERROR: insert or update on table "submissions" violates foreign key constraint "fk_rails_61cac0823d" DETAIL: Key (assignment_id)=(248083) is not present in table "assignments". #v- In all cases the problem is missing c44s16539.assignments with is = 248083. This time it looks that only one row is missing: #v+ Pg14# select max(id) from c44s16539.assignments where id < 248083; max ──────── 248082 (1 row) Pg14# select min(id) from c44s16539.assignments where id > 248083; min ──────── 248084 (1 row) #v- Schema is complicated. 76 columns. On pg12 side one column is dropped. 22 indexes, 9 fkeys from this table (assignments) to others, ~ 35 fkeys pointing to this table (but only 3 have rows that reference the missing record. Some informationa bout the record: #v+ Pg12# select ctid, xmin, cmin, xmax, cmax, id, created_at, updated_at from c44s16539.assignments where id = 248083 \gx ─[ RECORD 1 ]────────────────────────── ctid │ (24192,1) xmin │ 472291499 cmin │ 12 xmax │ 472291499 cmax │ 12 id │ 248083 created_at │ 2023-11-07 15:50:05.506077 updated_at │ 2023-11-07 15:51:28.738893 #v- logs for when it was added to replication: #v+ 2023-11-07 15:47:27.898 UTC,"postgres","dbname",2333,"[local]",654a5c0f.91d,39,"ALTER PUBLICATION",2023-11-07 15:47:27 UTC,6/0,0,LOG,00000,"duration: 1.476 ms",,,,,,,,,"psql" 2023-11-07 15:47:27.899 UTC,"postgres","dbname",2333,"[local]",654a5c0f.91d,40,"idle",2023-11-07 15:47:27 UTC,6/1209097693,0,LOG,00000,"statement: ALTER PUBLICATION focal14 ADD TABLE ONLY c247s1094.messages_2022_50;",,,,,,,,,"psql" 2023-11-07 15:47:27.900 UTC,"postgres","dbname",2333,"[local]",654a5c0f.91d,41,"ALTER PUBLICATION",2023-11-07 15:47:27 UTC,6/0,0,LOG,00000,"duration: 1.493 ms",,,,,,,,,"psql" 2023-11-07 15:47:27.900 UTC,"postgres","dbname",2333,"[local]",654a5c0f.91d,42,"idle",2023-11-07 15:47:27 UTC,6/1209097694,0,LOG,00000,"statement: ALTER PUBLICATION focal14 ADD TABLE ONLY c44s16539.assignments;",,,,,,,,,"psql" 2023-11-07 15:47:27.902 UTC,"postgres","dbname",2333,"[local]",654a5c0f.91d,43,"ALTER PUBLICATION",2023-11-07 15:47:27 UTC,6/0,0,LOG,00000,"duration: 1.936 ms",,,,,,,,,"psql" 2023-11-07 15:47:27.902 UTC,"postgres","dbname",2333,"[local]",654a5c0f.91d,44,"idle",2023-11-07 15:47:27 UTC,6/1209097695,0,LOG,00000,"statement: ALTER PUBLICATION focal14 ADD TABLE ONLY c39s5131.messages_2023_20;",,,,,,,,,"psql" 2023-11-07 15:47:27.903 UTC,"postgres","dbname",2333,"[local]",654a5c0f.91d,45,"ALTER PUBLICATION",2023-11-07 15:47:27 UTC,6/0,0,LOG,00000,"duration: 1.292 ms",,,,,,,,,"psql" #v- It is interesting that the time when the row was inserted (created_at) is always "around" the time that the table was added to publication... Just like with the other case, I can leave it in current state for a day, so if you'd need more information from it, let me know. Best regards, depesz