From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
---|---|
To: | kuroda(dot)hayato(at)fujitsu(dot)com |
Cc: | amit(dot)kapila16(at)gmail(dot)com, osumi(dot)takamichi(at)fujitsu(dot)com, smithpb2250(at)gmail(dot)com, vignesh21(at)gmail(dot)com, shveta(dot)malik(at)gmail(dot)com, dilipbalaut(at)gmail(dot)com, euler(at)eulerto(dot)com, m(dot)melihmutlu(at)gmail(dot)com, andres(at)anarazel(dot)de, marcos(at)f10(dot)com(dot)br, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Time delayed LR (WAS Re: logical replication restrictions) |
Date: | 2023-01-25 01:45:25 |
Message-ID: | 20230125.104525.433115861591453756.horikyota.ntt@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Sorry for making you bothered by this.
At Tue, 24 Jan 2023 10:12:40 +0000, "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com> wrote in
> > > Couldn't we maintain an additional static variable "last_applied"
> > > along with last_received?
> > >
> >
> > It won't be easy to maintain the meaning of last_applied because there
> > are cases where we don't apply the change directly. For example, in
> > case of streaming xacts, we will just keep writing it to the file,
> > now, say, due to some reason, we have to send the feedback, then it
> > will not allow you to update the latest write locations. This would
> > then become different then what we are doing without the patch.
> > Another point to think about is that we also need to keep the variable
> > updated for keep-alive ('k') messages even though we don't apply
> > anything in that case. Still, other cases to consider are where we
> > have mix of streaming and non-streaming transactions.
>
> I have tried to implement that, but it might be difficult because of a corner
> case related with the initial data sync.
>
> First of all, I have made last_applied to update when
>
> * transactions are committed, prepared, or aborted
> * apply worker receives keepalive message.
Yeah, I vagurly thought that it is enough that the update happens just
befor existing send_feecback() calls. But it turned out to introduce
another unprincipledness..
> I thought during the initial data sync, we must not update the last applied
> triggered by keepalive messages, so following lines were added just after
> updating last_received.
>
> ```
> + if (last_applied < end_lsn && AllTablesyncsReady())
> + last_applied = end_lsn;
> ```
Maybe, the name "last_applied" made you confused. As I mentioned in
another message, the variable points to the remote LSN of last
"processed" 'w/k' messages.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2023-01-25 01:48:56 | Re: plpython vs _POSIX_C_SOURCE |
Previous Message | Justin Pryzby | 2023-01-25 01:43:49 | Re: GUCs to control abbreviated sort keys |