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 1qyVoV-008tJu-UP for pgsql-bugs@arkaria.postgresql.org; Thu, 02 Nov 2023 11:24:39 +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 1qyVoU-00D0FX-9u for pgsql-bugs@arkaria.postgresql.org; Thu, 02 Nov 2023 11:24:38 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qyVoU-00D0FP-1n for pgsql-bugs@lists.postgresql.org; Thu, 02 Nov 2023 11:24:38 +0000 Received: from lana.depesz.com ([88.198.49.178] helo=depesz.com) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qyVoR-003b00-EU for pgsql-bugs@lists.postgresql.org; Thu, 02 Nov 2023 11:24:36 +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; bh=xb1hV4eWZYfvPDhK5TWGFR3IOE5xBbOypA6U+N7Bd+Y=; b=RqyzNS7m57+Ks4W7n2igjWL90w 9ieR2+H+Zp7IRhYM6oUO7qR9a34NqtaAsbL4IFgxtJFSHvkPIS2xDTEV/zWZXVt3nQtMVVGDCarXe HH6s8MWh6nCak7zHfbe8XOmKJLH2TnddO+HwPPmSiaSh1YKnzXcClKQxdLKb15ctCO2o=; Received: from depesz by depesz.com with local (Exim 4.94.2) (envelope-from ) id 1qyVoO-000e9L-A0; Thu, 02 Nov 2023 12:24:32 +0100 Date: Thu, 2 Nov 2023 12:24:32 +0100 From: hubert depesz lubaczewski Sender: depesz@depesz.com To: "Hayato Kuroda (Fujitsu)" Cc: 'Kyotaro Horiguchi' , "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 In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Thu, Nov 02, 2023 at 03:17:03AM +0000, Hayato Kuroda (Fujitsu) wrote: > Dear Horiguchi-san, > > > I'm not well-versed in the details of logical replication, but does > > logical replication inherently operate in such a way that it fully > > maintains relationships between tables? If not, isn't it possible that > > the issue in question is not about missing referenced data, but merely > > a temporary delay? > > I assumed that tuples referred by FK existed before synchronization or during that. > In this case, IIUC the status is never 'r' before they are replicated. Thought? > > Dear Depesz, > > Is above assumption right? > > Also, I suggest you that pg_stat_replicaiton can be checked on publisher when you > meet the failure again. If pg_stat_replication.replay_lsn is much behind > pg_stat_replication.sent_lsn, the replication may be delayed so that the tuples > are not appeared. pg_stat_subscription on subscriber has similar infos with replay_lsn. > > Note that pg_stat_replication may be not updated if feedbacks from a subscriber > is disabled. > > https://www.postgresql.org/docs/14/monitoring-stats.html#MONITORING-PG-STAT-SUBSCRIPTION Whenever the problem happens lag is virtually nonexistent. We test it by adding new rows to couple of tables, and verify that these rows show up on subscriber. They did. Again - replication was *working* with the exception of block of rows from one (so far it never happened on more than one) table that was missing. Best regards, depesz