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
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 |