Re: Perform streaming logical transactions by background workers and parallel apply - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Perform streaming logical transactions by background workers and parallel apply
Date
Msg-id CAA4eK1KjU7Lzg4_F2HLybHZrYhSXwLs0yke1f2tzDAL3KzVBnw@mail.gmail.com
Whole thread Raw
In response to RE: Perform streaming logical transactions by background workers and parallel apply  ("kuroda.hayato@fujitsu.com" <kuroda.hayato@fujitsu.com>)
List pgsql-hackers
On Thu, Sep 22, 2022 at 4:50 PM kuroda.hayato@fujitsu.com
<kuroda.hayato@fujitsu.com> wrote:
>
> Hi Amit,
>
> > > I checked other flags that are set by signal handlers, their datatype seemed to
> > be sig_atomic_t.
> > > Is there any reasons that you use normal bool? It should be changed if not.
> > >
> >
> > It follows the logic similar to ParallelMessagePending. Do you see any
> > problem with it?
>
> Hmm, one consideration is:
> what will happen if the signal handler HandleParallelApplyMessageInterrupt() is fired during
"ParallelApplyMessagePending= false;"?
 
> IIUC sig_atomic_t has been needed to avoid writing to same data at the same time.
>

But we do call HOLD_INTERRUPTS() before we do
"ParallelApplyMessagePending = false;", so that should not happen.
However, I think it would be better to use sig_atomic_t here for the
sake of consistency.

I think you can start a separate thread to check if we can change
ParallelMessagePending to make it consistent with other such
variables.

-- 
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: CI and test improvements
Next
From: Ashutosh Sharma
Date:
Subject: Re: binary version of pg_current_wal_insert_lsn and pg_walfile_name functions