From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | Alexey Kondratov <a(dot)kondratov(at)postgrespro(dot)ru>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, dim(at)tapoueh(dot)org, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Simon Riggs <simon(at)2ndquadrant(dot)com> |
Subject: | Re: Physical replication slot advance is not persistent |
Date: | 2020-07-10 01:45:57 |
Message-ID: | 20200710014557.GG11153@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jul 09, 2020 at 04:12:49PM +0530, Amit Kapila wrote:
> On Fri, Jun 19, 2020 at 12:16 AM Alexey Kondratov
> <a(dot)kondratov(at)postgrespro(dot)ru> wrote:
>> 1. Both ReplicationSlotsComputeRequiredXmin() and
>> ReplicationSlotsComputeRequiredLSN() may have already been done in the
>> LogicalConfirmReceivedLocation() if it was a logical slot.
>>
>
> I think it is not done in all cases, see the else part in
> LogicalConfirmReceivedLocation.
>
> LogicalConfirmReceivedLocation
> {
> ..
> else
> {
> SpinLockAcquire(&MyReplicationSlot->mutex);
> MyReplicationSlot->data.confirmed_flush = lsn;
> SpinLockRelease(&MyReplicationSlot->mutex);
> }
> ..
> }
Thanks Amit, and sorry for the late catchup. The choice of computing
the minimum LSN and xmin across all slots at the end of
pg_replication_slot_advance() is deliberate. That's more consistent
with the slot creation, copy and drop for one, and that was also the
intention of the original code (actually a no-op as introduced by
9c7d06d). This also brings an interesting property to the advancing
routines to be able to enforce a recomputation without having to wait
for a checkpoint or a WAL sender to do so. So, while there may be
cases where we don't need this recomputation to happen, and there may
be cases where it may be a waste, the code simplicity and consistency
are IMO reasons enough to keep this code as it is now.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | torikoshia | 2020-07-10 01:49:11 | Re: Is it useful to record whether plans are generic or custom? |
Previous Message | Peter Geoghegan | 2020-07-10 01:21:07 | Re: Default setting for enable_hashagg_disk |