Re: BUG #17055: Logical replication worker crashes when applying update of row that dose not exist in target partiti

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Amit Langote <amitlangote09(at)gmail(dot)com>, sbernikov(at)gmail(dot)com, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: BUG #17055: Logical replication worker crashes when applying update of row that dose not exist in target partiti
Date: 2021-06-12 00:21:47
Message-ID: YMP+Gx2S8meYYHW4@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Fri, Jun 11, 2021 at 04:15:20PM -0400, Tom Lane wrote:
> Done now. It was a highly worthwhile exercise, too, because I stumbled
> over two *other* bugs in this code while I was at it.
>
> BTW, I intentionally reworded the DEBUG messages to make sure we could
> tell the partitioned case apart from the non-partitioned one.

I have two comments about the TAP portion of ab55d74.

+$node_subscriber->append_conf('postgresql.conf', "log_min_messages = debug1");
+$node_subscriber->reload;
Wouldn't it be better to make sure that the change is effective before
moving on to the end of the test?

+my $logfile = slurp_file($node_subscriber->logfile());
+ok( $logfile =~
+ qr/logical replication did not find row to be updated in replication target relation "tab_full_pk"/,
+ 'update target row is missing');
I think that it would be better here to grab the log location before
running the queries that will be matched with the logs, then pass down
the location to slurp_file().
--
Michael

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2021-06-12 00:31:30 Re: BUG #17055: Logical replication worker crashes when applying update of row that dose not exist in target partiti
Previous Message Andrew Dunstan 2021-06-11 22:03:28 Re: BUG #17056: Segmentation fault on altering the type of the foreign table column with a default