Re: Avoid unnecessary ReplicationSlotControl lwlock acquistion - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: Avoid unnecessary ReplicationSlotControl lwlock acquistion
Date
Msg-id CA+fd4k4uYSXeXYCMu0EBHEBEnktrNm-PeWRqPG1nNR1BoTCpLQ@mail.gmail.com
Whole thread Raw
In response to Re: Avoid unnecessary ReplicationSlotControl lwlock acquistion  (Andres Freund <andres@anarazel.de>)
Responses Re: Avoid unnecessary ReplicationSlotControl lwlock acquistion  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Tue, 25 Aug 2020 at 11:42, Andres Freund <andres@anarazel.de> wrote:
>
> Hi,
>
> On August 24, 2020 7:38:39 PM PDT, Masahiko Sawada <masahiko.sawada@2ndquadrant.com> wrote:
> >Hi all,
> >
> >While testing with DTrace, I realized we acquire
> >ReplicationSlotControl lwlock at some places even when
> >max_replication_slots is set to 0. For instance, we call
> >ReplicationSlotCleanup() within PostgresMian() when an error happens
> >and acquire ReplicationSlotControl lwlock.
> >
> >The attached patch fixes some functions so that we quickly return if
> >max_replication_slots is set to 0.
>
> Why is it worth doing so?

I think we can avoid unnecessary overhead caused by acquiring and
releasing that lwlock itself. The functions modified by this patch are
called during error cleanup or checkpoints.  For the former case,
since it’s not a commit path the benefit might not be large on common
workload but it might help to reduce the latency on a workload whose
abort rate is relatively high. Also looking at other functions in
slot.c, other functions also do so. I think these are also for
preventing unnecessary overhead.

Regards,

--
Masahiko Sawada            http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Avoid unnecessary ReplicationSlotControl lwlock acquistion
Next
From: Bruce Momjian
Date:
Subject: Re: "cert" + clientcert=verify-ca in pg_hba.conf?