RE: pg_upgrade and logical replication

From: "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>
To: 'vignesh C' <vignesh21(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Justin Pryzby <pryzby(at)telsasoft(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Peter Smith <smithpb2250(at)gmail(dot)com>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: RE: pg_upgrade and logical replication
Date: 2024-03-27 06:59:58
Message-ID: TYCPR01MB120774AF72CB58C7D35062536F5342@TYCPR01MB12077.jpnprd01.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dear Vignesh,

>
> Recently there was a failure in 004_subscription tap test at [1].
> In this failure, the tab_upgraded1 table was expected to have 51
> records but has only 50 records. Before the upgrade both publisher and
> subscriber have 50 records.

Good catch!

> After the upgrade we have inserted one record in the publisher, now
> tab_upgraded1 will have 51 records in the publisher. Then we start the
> subscriber after changing max_logical_replication_workers so that
> apply workers get started and apply the changes received. After
> starting we enable regress_sub5, wait for sync of regress_sub5
> subscription and check for tab_upgraded1 and tab_upgraded2 table data.
> In a few random cases the one record that was inserted into
> tab_upgraded1 table will not get replicated as we have not waited for
> regress_sub4 subscription to apply the changes from the publisher.
> The attached patch has changes to wait for regress_sub4 subscription
> to apply the changes from the publisher before verifying the data.
>
> [1] -
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mamba&dt=2024-03-
> 26%2004%3A23%3A13

Yeah, I think it is an oversight in f17529. Previously subscriptions which
receiving changes were confirmed to be caught up, I missed to add the line while
restructuring the script. +1 for your fix.

Best Regards,
Hayato Kuroda
FUJITSU LIMITED
https://www.fujitsu.com/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Donghang Lin 2024-03-27 07:03:08 Re: Parallel Bitmap Heap Scan reports per-worker stats in EXPLAIN ANALYZE
Previous Message Bharath Rupireddy 2024-03-27 06:58:06 Re: pgsql: Track last_inactive_time in pg_replication_slots.