Re: BUG #17055: Logical replication worker crashes when applying update of row that dose not exist in target partiti
От | Tom Lane |
---|---|
Тема | Re: BUG #17055: Logical replication worker crashes when applying update of row that dose not exist in target partiti |
Дата | |
Msg-id | 1881335.1623423667@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #17055: Logical replication worker crashes when applying update of row that dose not exist in target partiti (Amit Langote <amitlangote09@gmail.com>) |
Ответы |
Re: BUG #17055: Logical replication worker crashes when applying update of row that dose not exist in target partiti
|
Список | 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
В списке pgsql-bugs по дате отправления: