RE: Reload configuration more frequently in apply worker.

From: "Zhijie Hou (Fujitsu)" <houzj(dot)fnst(at)fujitsu(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: RE: Reload configuration more frequently in apply worker.
Date: 2023-05-19 03:50:04
Message-ID: OS0PR01MB5716217D0FC4E3BB2C0D7428947C9@OS0PR01MB5716.jpnprd01.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wednesday, May 17, 2023 11:05 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Wed, May 17, 2023 at 7:18 AM Zhijie Hou (Fujitsu) <houzj(dot)fnst(at)fujitsu(dot)com>
> wrote:
> >
> > Currently, the main loop of apply worker looks like below[1]. Since
> > there are two loops, the inner loop will keep receiving and applying
> > message from publisher until no more message left. The worker only
> > reloads the configuration in the outer loop. This means if the
> > publisher keeps sending messages (it could keep sending multiple
> > transactions), the apply worker won't get a chance to update the GUCs.
> >
>
> Apart from that, I think in rare cases, it seems possible that after the apply
> worker has waited for the data and just before it receives the new replication
> data/message, the reload happens, then it won't get a chance to process the
> reload before processing the new message.
> I think such a theory can explain the rare BF failure you pointed out later in the
> thread. Does that make sense?

Yes, that makes sense. That's another case where we would miss the reload and I think
is the reason for the failure because the apply worker has finished applying changes(which
means it's idle) before the failed case.

Best Regards,
Hou zj

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jonathan S. Katz 2023-05-19 04:17:50 PostgreSQL 16 Beta 1 release announcement draft
Previous Message Richard Guo 2023-05-19 03:23:33 Re: Assert failure of the cross-check for nullingrels