public inbox for [email protected]
help / color / mirror / Atom feedFrom: Tomas Vondra <[email protected]>
To: Ashutosh Bapat <[email protected]>
Cc: Amit Kapila <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Cc: Masahiko Sawada <[email protected]>
Cc: Peter Eisentraut <[email protected]>
Subject: Re: logical decoding and replication of sequences, take 2
Date: Sat, 29 Jul 2023 14:23:29 +0200
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAExHW5uCUSNTn421eH5d2pVDh-DM=SJ3sERsKu-aQrP6ZPh08g@mail.gmail.com>
References: <[email protected]>
<CAExHW5v_vVqkhF4ehST9EzpX1L3bemD1S+kTk_-ZVu_ir-nKDw@mail.gmail.com>
<CAExHW5vCxjxCzDsZThMRCnBYGaJsJyc5WVZeHQTpvBFMFpDbdg@mail.gmail.com>
<CAExHW5u43MPfwUxWafpKrBEASn=w0=Am==W02nbY7=LbLwus6A@mail.gmail.com>
<[email protected]>
<CAExHW5s6kMKYHo1eQppvzZQyitvZcnAyKNU6xvbKwbPuTOXJkQ@mail.gmail.com>
<CAExHW5vHRgjWzi6zZbgCs97eW9U7xMtzXEQK+aepuzoGDsDNtg@mail.gmail.com>
<CAA4eK1+KFeHajszmqHKZuVHTM4cMgMuQ0xEnGiTaKJM-XGU-aA@mail.gmail.com>
<[email protected]>
<CAA4eK1+MuR5Hj7TOpuUoSnmE02re1KUUFTzFrah6-hejQ6z4aQ@mail.gmail.com>
<[email protected]>
<CAA4eK1KAP0BmfZG4Pcvt6=vcdWT7p5J0-MtJySPhnfj4aDYE-g@mail.gmail.com>
<CAA4eK1L+2bie=Yj5VSZqTRnoRCsvH=5sGh4bD76fnqSkLTkNLQ@mail.gmail.com>
<[email protected]>
<CAExHW5uCUSNTn421eH5d2pVDh-DM=SJ3sERsKu-aQrP6ZPh08g@mail.gmail.com>
On 7/28/23 14:44, Ashutosh Bapat wrote:
> On Wed, Jul 26, 2023 at 8:48 PM Tomas Vondra
> <[email protected]> wrote:
>>
>> Anyway, I was thinking about this a bit more, and it seems it's not as
>> difficult to use the page LSN to ensure sequences don't go backwards.
>> The 0005 change does that, by:
>>
>> 1) adding pg_sequence_state, that returns both the sequence state and
>> the page LSN
>>
>> 2) copy_sequence returns the page LSN
>>
>> 3) tablesync then sets this LSN as origin_startpos (which for tables is
>> just the LSN of the replication slot)
>>
>> AFAICS this makes it work - we start decoding at the page LSN, so that
>> we skip the increments that could lead to the sequence going backwards.
>>
>
> I like this design very much. It makes things simpler than complex.
> Thanks for doing this.
>
I agree it seems simpler. It'd be good to try testing / reviewing it a
bit more, so that it doesn't misbehave in some way.
> I am wondering whether we could reuse pg_sequence_last_value() instead
> of adding a new function. But the name of the function doesn't leave
> much space for expanding its functionality. So we are good with a new
> one. Probably some code deduplication.
>
I don't think we should do that, the pg_sequence_last_value() function
is meant to do something different. I don't think it'd be any simpler to
also make it do what pg_sequence_state() does would make it any simpler.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
view thread (46+ 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]
Subject: Re: logical decoding and replication of sequences, take 2
In-Reply-To: <[email protected]>
* 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