public inbox for [email protected]
help / color / mirror / Atom feedFrom: Takamichi Osumi (Fujitsu) <[email protected]>
To: 'Amit Kapila' <[email protected]>
To: Kyotaro Horiguchi <[email protected]>
Cc: [email protected] <[email protected]>
Cc: [email protected] <[email protected]>
Cc: Hayato Kuroda (Fujitsu) <[email protected]>
Cc: [email protected] <[email protected]>
Cc: [email protected] <[email protected]>
Cc: [email protected] <[email protected]>
Cc: [email protected] <[email protected]>
Cc: [email protected] <[email protected]>
Cc: [email protected] <[email protected]>
Cc: [email protected] <[email protected]>
Subject: RE: Time delayed LR (WAS Re: logical replication restrictions)
Date: Tue, 24 Jan 2023 12:32:03 +0000
Message-ID: <TYCPR01MB8373AFEC3BB6CCE811CDB2F4EDC99@TYCPR01MB8373.jpnprd01.prod.outlook.com> (raw)
In-Reply-To: <CAA4eK1JTTCcMrsMAmz9LSEE6gvGHnTK0u1w0kg9hV6rcFFB5hQ@mail.gmail.com>
References: <CAHut+Puwrb_DEV_7ANSKrQr23-dAmL9vrNV8ww7XsAP+kej0uw@mail.gmail.com>
<TYCPR01MB8373BED9E390C4839AF56685EDC59@TYCPR01MB8373.jpnprd01.prod.outlook.com>
<TYCPR01MB8373A23EFC25B22CB132383AEDCB9@TYCPR01MB8373.jpnprd01.prod.outlook.com>
<[email protected]>
<CAA4eK1JTTCcMrsMAmz9LSEE6gvGHnTK0u1w0kg9hV6rcFFB5hQ@mail.gmail.com>
On Tuesday, January 24, 2023 3:58 PM Amit Kapila <[email protected]> wrote:
> > send_feedback():
> > + * If the subscriber side apply is delayed (because of time-delayed
> > + * replication) then do not tell the publisher that the received latest
> > + * LSN is already applied and flushed, otherwise, it leads to the
> > + * publisher side making a wrong assumption of logical replication
> > + * progress. Instead, we just send a feedback message to avoid a
> publisher
> > + * timeout during the delay.
> > */
> > - if (!have_pending_txes)
> > + if (!have_pending_txes && !in_delayed_apply)
> > flushpos = writepos = recvpos;
> >
> > Honestly I don't like this wart. The reason for this is the function
> > assumes recvpos = applypos but we actually call it while holding
> > unapplied changes, that is, applypos < recvpos.
> >
> > 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.
Agreed. This will change some existing behaviors. So, didn't conduct this change in the latest patch [1].
[1] - https://www.postgresql.org/message-id/TYCPR01MB8373DC1881F382B4703F26E0EDC99%40TYCPR01MB8373.jpnprd0...
Best Regards,
Takamichi Osumi
view thread (6+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: RE: Time delayed LR (WAS Re: logical replication restrictions)
In-Reply-To: <TYCPR01MB8373AFEC3BB6CCE811CDB2F4EDC99@TYCPR01MB8373.jpnprd01.prod.outlook.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox