Re: BUG #17055: Logical replication worker crashes when applying update of row that dose not exist in target partiti
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Amit Langote <amitlangote09@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>, sbernikov@gmail.com,
PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Date: 2021-06-11T15:01:07Z
Lists: pgsql-bugs
Amit Langote <amitlangote09@gmail.com> writes: > On Fri, Jun 11, 2021 at 3:26 PM Michael Paquier <michael@paquier.xyz> 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
Commits
-
Improve log pattern detection in recently-added TAP tests
- fad9c8e93a65 13.4 landed
- bfd96b7a3dc2 14.0 landed
-
Fix multiple crasher bugs in partitioned-table replication logic.
- ab55d742eb71 14.0 landed
- b270713fd44b 13.4 landed