Re: logical decoding and replication of sequences, take 2 - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: logical decoding and replication of sequences, take 2
Date
Msg-id CAA4eK1LiVowttaGmVCnvtOJNTPhj+xFaMpB-WBkMefejdq3ROQ@mail.gmail.com
Whole thread Raw
In response to Re: logical decoding and replication of sequences, take 2  (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>)
Responses Re: logical decoding and replication of sequences, take 2
List pgsql-hackers
On Thu, Aug 17, 2023 at 7:13 PM Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:
>
> On Wed, Aug 16, 2023 at 7:56 PM Tomas Vondra
> <tomas.vondra@enterprisedb.com> wrote:
> >
> > >
> > > But whether or not that's the case, downstream should not request (and
> > > hence receive) any changes that have been already applied (and
> > > committed) downstream as a principle. I think a way to achieve this is
> > > to update the replorigin_session_origin_lsn so that a sequence change
> > > applied once is not requested (and hence sent) again.
> > >
> >
> > I guess we could update the origin, per attached 0004. We don't have
> > timestamp to set replorigin_session_origin_timestamp, but it seems we
> > don't need that.
> >
> > The attached patch merges the earlier improvements, except for the part
> > that experimented with adding a "fake" transaction (which turned out to
> > have a number of difficult issues).
>
> 0004 looks good to me.


+ {
  CommitTransactionCommand();
+
+ /*
+ * Update origin state so we don't try applying this sequence
+ * change in case of crash.
+ *
+ * XXX We don't have replorigin_session_origin_timestamp, but we
+ * can just leave that set to 0.
+ */
+ replorigin_session_origin_lsn = seq.lsn;

IIUC, your proposal is to update the replorigin_session_origin_lsn, so
that after restart, it doesn't use some prior origin LSN to start with
which can in turn lead the sequence to go backward. If so, it should
be updated before calling CommitTransactionCommand() as we are doing
in apply_handle_commit_internal(). If that is not the intention then
it is not clear to me how updating replorigin_session_origin_lsn after
commit is helpful.

>
 But I need to review the impact of not setting
> replorigin_session_origin_timestamp.
>

This may not have a direct impact on built-in replication as I think
we don't rely on it yet but we need to think of out-of-core solutions.
I am not sure if I understood your proposal as per my previous comment
but once you clarify the same, I'll also try to think on the same.

--
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: jian he
Date:
Subject: Re: Extract numeric filed in JSONB more effectively
Next
From: Michael Paquier
Date:
Subject: Re: Rethink the wait event names for postgres_fdw, dblink and etc