Re: Reload configuration more frequently in apply worker.

On Wed, May 17, 2023 at 7:18 AM Zhijie Hou (Fujitsu)
<houzj.fnst@fujitsu.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?

> [1]
> for(;;) /* outer loop */
> {
>         for(;;) /* inner loop */
>         {
>                 len = walrcv_receive()
>                 if (len == 0)
>                         break;
>                 ...
>                 apply change
>         }
>
>         ...
>         if (ConfigReloadPending)
>         {
>                 ConfigReloadPending = false;
>                 ProcessConfigFile(PGC_SIGHUP);
>         }
>         ...
> }
>
> I think it would be better that the apply worker can reflect user's
> configuration changes sooner. To achieve this, we can add one more
> ProcessConfigFile() call in the inner loop. Attach the patch for the same. What
> do you think ?
>

I think it appears to somewhat match what Tom said in the third point
in his email [1].

> BTW, I saw one BF failure[2] (it's very rare and only happened once in 4
> months) which I think is due to the low frequent reload in apply worker.
>
> The attached tap test shows how the failure happened.
>

I haven't yet tried to reproduce it but will try later sometime.
Thanks for your analysis.

[1] - https://www.postgresql.org/message-id/2138662.1623460441%40sss.pgh.pa.us

--
With Regards,
Amit Kapila.