Re: [HACKERS] make async slave to wait for lsn to be replayed - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: [HACKERS] make async slave to wait for lsn to be replayed
Date
Msg-id CAA4eK1+uchxdP8B3Kij-1h8xkc-UrUvicmVx895ONH58xDt4XQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] make async slave to wait for lsn to be replayed  (Alexander Korotkov <a.korotkov@postgrespro.ru>)
Responses Re: [HACKERS] make async slave to wait for lsn to be replayed
List pgsql-hackers
On Tue, Apr 7, 2020 at 5:56 AM Alexander Korotkov
<a.korotkov@postgrespro.ru> wrote:
>
> On Tue, Apr 7, 2020 at 12:58 AM Kartyshov Ivan
> <i.kartyshov@postgrespro.ru> wrote:
> > On 2020-04-04 03:14, Alexander Korotkov wrote:
> > > I think that now we would be fine with single LSN and single TIMEOUT.
> > > In future we may add multiple LSNs/TIMEOUTs or/and support for
> > > expressions as LSNs/TIMEOUTs if we figure out it's necessary.
> > >
> > > I also think it's good to couple waiting for lsn with beginning of
> > > transaction is good idea.  Separate WAIT FOR LSN statement called in
> > > the middle of transaction looks problematic for me. Imagine we have RR
> > > isolation and already acquired the snapshot.  Then out snapshot can
> > > block applying wal records, which we are waiting for.  That would be
> > > implicit deadlock.  It would be nice to evade such deadlocks by
> > > design.
> > Ok, here is a new version of patch with single LSN and TIMEOUT.
>
> I think this quite small feature, which already received quite amount
> of review.  The last version is very pinched.  But I think it would be
> good to commit some very basic version, which is at least some
> progress in the area and could be extended in future.  I'm going to
> pass trough the code tomorrow and commit this unless I found major
> issues or somebody objects.
>

I have gone through this thread and skimmed through the patch and I am
not sure if we can say that this patch is ready to go.  First, I don't
think we have a consensus on the syntax being used in the patch
(various people didn't agree to LSN specific syntax).  They wanted a
more generic syntax and I see that we tried to implement it and it
turns out to be a bit complex but that doesn't mean we just give up on
the idea and take the simplest approach and that too without a broader
agreement.  Second, on my quick review, it seems there are a few
things like error handling, interrupt checking which need more work.

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: EINTR while resizing dsm segment.
Next
From: Jehan-Guillaume de Rorthais
Date:
Subject: Re: Using the rr debugging tool to debug Postgres