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 1lriem-0003w2-Vq for pgsql-bugs@arkaria.postgresql.org; Fri, 11 Jun 2021 15:01:12 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lriel-0006GM-Nf for pgsql-bugs@arkaria.postgresql.org; Fri, 11 Jun 2021 15:01:11 +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 1lriel-0006GE-HQ for pgsql-bugs@lists.postgresql.org; Fri, 11 Jun 2021 15:01:11 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lriej-0007oF-Ji for pgsql-bugs@lists.postgresql.org; Fri, 11 Jun 2021 15:01:11 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 15BF17nu1881336; Fri, 11 Jun 2021 11:01:07 -0400 From: Tom Lane To: Amit Langote cc: Michael Paquier , sbernikov@gmail.com, PostgreSQL mailing lists Subject: Re: BUG #17055: Logical replication worker crashes when applying update of row that dose not exist in target partiti In-reply-to: References: <17055-9ba800ec8522668b@postgresql.org> <1828113.1623370641@sss.pgh.pa.us> Comments: In-reply-to Amit Langote message dated "Fri, 11 Jun 2021 16:30:03 +0900" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1881334.1623423667.1@sss.pgh.pa.us> Date: Fri, 11 Jun 2021 11:01:07 -0400 Message-ID: <1881335.1623423667@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Amit Langote writes: > On Fri, Jun 11, 2021 at 3:26 PM Michael Paquier wrote: >> It seems to me that it would make sense to have some coverage. We've >> caught issues in the past in this area, particularly with buildfarm >> animals running CLOBBER_CACHE_ALWAYS. > I thought about it for a minute when writing the patch I posted, but > wasn't really sure what the test case would look like. The only > external proof that the case worked correctly, AFAICS, is the DEBUG1 > message that's written to the log. How do we add a test case with > that? I know you mentioned an idea before to check/grep the log for > such cases. Is that how? I see from the coverage report that *none* of the did-not-find-tuple code paths in worker.c are exercised. This does not seem OK. I agree that probably the only way to have a test case is to kick up the debug level to DEBUG1 and grep the log to confirm that the message is there. IIRC, we already have infrastructure for grepping the log, so this shouldn't be that hard. Will work on it today. (Meanwhile, thanks for the diagnosis and patch!) regards, tom lane