From: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Ronan Dunklau <ronan(dot)dunklau(at)aiven(dot)io>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
Subject: | Re: pg_receivewal starting position |
Date: | 2021-10-24 13:50:57 |
Message-ID: | CALj2ACXm4UsFjHqAQzO8yYFmmF72FnbPVOmtATmgJ7g=z44_vA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Oct 24, 2021 at 12:21 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Sun, Oct 24, 2021 at 09:08:01AM +0530, Bharath Rupireddy wrote:
> > pg_get_replication_slots holds the ReplicationSlotControlLock until
> > the end of the function so it can be assured that *slot contents will
> > not change. In ReadReplicationSlot, the ReplicationSlotControlLock is
> > released immediately after taking *slot pointer into slot_contents.
> > Isn't it better if we hold the lock until the end of the function so
> > that we can avoid the slot contents becoming stale problems?
>
> The reason is different in the case of pg_get_replication_slots(). We
> have to hold ReplicationSlotControlLock for the whole duration of the
> shared memory scan to return back to the user a consistent set of
> information to the user, for all the slots.
Thanks. I've no further comments on the v10 patch.
Regards,
Bharath Rupireddy.
From | Date | Subject | |
---|---|---|---|
Next Message | Bharath Rupireddy | 2021-10-24 14:28:16 | Re: Allow pg_signal_backend members to use pg_log_backend_memory_stats(). |
Previous Message | Thomas Munro | 2021-10-24 09:50:15 | Re: [PATCH] Make ENOSPC not fatal in semaphore creation |