On Thu, Sep 29, 2022 at 3:20 PM kuroda.hayato@fujitsu.com
<kuroda.hayato@fujitsu.com> wrote:
>
> Dear Hou,
>
> Thanks for updating patch. I will review yours soon, but I reply to your comment.
>
> > > 04. applyparallelworker.c - LogicalParallelApplyLoop()
> > >
> > > ```
> > > + shmq_res = shm_mq_receive(mqh, &len, &data, false);
> > > ...
> > > + if (ConfigReloadPending)
> > > + {
> > > + ConfigReloadPending = false;
> > > + ProcessConfigFile(PGC_SIGHUP);
> > > + }
> > > ```
> > >
> > >
> > > Here the parallel apply worker waits to receive messages and after dispatching
> > > it ProcessConfigFile() is called.
> > > It means that .conf will be not read until the parallel apply worker receives new
> > > messages and apply them.
> > >
> > > It may be problematic when users change log_min_message to debugXXX for
> > > debugging but the streamed transaction rarely come.
> > > They expected that detailed description appears on the log from next
> > > streaming chunk, but it does not.
> > >
> > > This does not occur in leader worker when it waits messages from publisher,
> > > because it uses libpqrcv_receive(), which works asynchronously.
> > >
> > > I 'm not sure whether it should be documented that the evaluation of GUCs may
> > > be delayed, how do you think?
> >
> > I changed the shm_mq_receive to asynchronous mode which is also consistent
> > with
> > what we did for Gather node when reading data from parallel query workers.
>
> I checked your implementation, but it seemed that the parallel apply worker will not sleep
> even if there are no messages or signals. It might be very inefficient.
>
> In gather node - gather_readnext(), the same way is used, but I think there is a premise
> that the wait-time is short because it is related with only one gather node.
> In terms of parallel apply worker, however, we cannot predict the wait-time because
> it is related with the streamed transactions. If such transactions rarely come, parallel apply workers may spend many
CPUtime.
>
> I think we should wait during short time or until leader notifies, if shmq_res == SHM_MQ_WOULD_BLOCK.
> How do you think?
>
Can't we use WaitLatch in the case of SHM_MQ_WOULD_BLOCK as we are
using it for the same case at some other place in the code? We can use
the same nap time as we are using in the leader apply worker.
--
With Regards,
Amit Kapila.