Re: [HACKERS] make async slave to wait for lsn to be replayed

On Tue, Apr 7, 2020 at 5:56 AM Alexander Korotkov
<a(dot)korotkov(at)postgrespro(dot)ru> wrote:
>
> On Tue, Apr 7, 2020 at 12:58 AM Kartyshov Ivan
> <i(dot)kartyshov(at)postgrespro(dot)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