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.kondra...@postgrespro.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
signature.asc
Description: PGP signature
