Re: Problem with synchronous replication - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: Problem with synchronous replication
Date
Msg-id CAHGQGwEW1P6LS36go9EF=tx3kVaLZrmm=YkEBs3GXZGpT9j4hg@mail.gmail.com
Whole thread Raw
In response to Re: Problem with synchronous replication  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Problem with synchronous replication
List pgsql-hackers
On Thu, Oct 31, 2019 at 11:12 AM Michael Paquier <michael@paquier.xyz> wrote:
>
> On Wed, Oct 30, 2019 at 05:43:04PM +0900, Kyotaro Horiguchi wrote:
> > At Wed, 30 Oct 2019 17:21:17 +0900, Fujii Masao <masao.fujii@gmail.com> wrote in
> >> This change causes every ending backends to always take the exclusive lock
> >> even when it's not in SyncRep queue. This may be problematic, for example,
> >> when terminating multiple backends at the same time? If yes,
> >> it might be better to check SHMQueueIsDetached() again after taking the lock.
> >> That is,
> >
> > I'm not sure how much that harms but double-checked locking
> > (releasing) is simple enough for reducing possible congestion here, I
> > think.
>
> FWIW, I could not measure any actual difference with pgbench -C, up to
> 500 sessions and an empty input file (just have one meta-command) and
> -c 20.
>
> I have added some comments in SyncRepCleanupAtProcExit(), and adjusted
> the patch with the suggestion from Fujii-san.  Any comments?

Thanks for the patch! Looks good to me.

Regards,

-- 
Fujii Masao



pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: [PATCH] Do not use StdRdOptions in Access Methods
Next
From: amul sul
Date:
Subject: Can avoid list_copy in recomputeNamespacePath() conditionally?