Re: Copy function for logical replication slots - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Copy function for logical replication slots
Date
Msg-id 20190218162824.3wsvuxwjaav6fqdc@alap3.anarazel.de
Whole thread Raw
In response to Re: Copy function for logical replication slots  (Masahiko Sawada <sawada.mshk@gmail.com>)
Responses Re: Copy function for logical replication slots  (Masahiko Sawada <sawada.mshk@gmail.com>)
List pgsql-hackers
Hi,

On 2019-02-18 16:57:07 +0900, Masahiko Sawada wrote:
> > Stupid question, but couldn't we optimize this to something like:
> >
> >     /*
> >      * First copy current data of the slot. Then install those in the
> >      * new slot. The src slot could have progressed while installing,
> >      * but the installed values prevent global horizons from progressing
> >      * further. Therefore a second copy is sufficiently up2date.
> >      */
> >     SpinLockAcquire(&src->mutex);
> >     copy_lsn = src->data.restart_lsn;
> >     copy_xid = ...;
> >     SpinLockRelease(&src->mutex);
> >
> >     /* install copied values */
> >
> >
> >     SpinLockAcquire(&src->mutex);
> >     /* copy data of slot again */
> >     SpinLockRelease(&src->mutex);
> >
> >     /* install again */
> >
> > ?
> 
> With this optimization since we don't need to acquire the source slot
> we can copy even from a slot that has already been acquired by
> someone, which is great. However is it possible that once released the
> first spinlock of the source slot it could be dropped and the global
> horizons can progress before installing the copied values?

Well, I'd not thought we'd do it without acquiring the other slot. But
that still seems to be easy enough to address, we just need to recheck
whether the slot still exists (with the right name) the second time we
acquire the spinlock?

Greetings,

Andres Freund


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Reporting script runtimes in pg_regress
Next
From: Andres Freund
Date:
Subject: Re: Use varargs macro for CACHEDEBUG