public inbox for [email protected]
help / color / mirror / Atom feedFrom: Petr Jelinek <[email protected]>
To: Amit Kapila <[email protected]>
Cc: Tomas Vondra <[email protected]>
Cc: Peter Eisentraut <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: logical decoding and replication of sequences
Date: Wed, 23 Mar 2022 13:46:29 +0100
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAA4eK1Jn-DttQ=4Pdh9YCe1w+zGbgC+0uR0sfg2RtkjiAPmB9g@mail.gmail.com>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<CAA4eK1Jro8hGX_hzXCznBr++suoDM7avEhFtiphPeDLPBOc=Ow@mail.gmail.com>
<[email protected]>
<CAA4eK1Jn-DttQ=4Pdh9YCe1w+zGbgC+0uR0sfg2RtkjiAPmB9g@mail.gmail.com>
> On 23. 3. 2022, at 12:50, Amit Kapila <[email protected]> wrote:
>
> On Tue, Mar 22, 2022 at 5:41 PM Petr Jelinek
> <[email protected] <mailto:[email protected]>> wrote:
>>
>>> On 22. 3. 2022, at 13:09, Amit Kapila <[email protected]> wrote:
>>>
>>> On Mon, Mar 21, 2022 at 4:25 AM Tomas Vondra
>>> <[email protected]> wrote:
>>>>
>>>> Hi,
>>>>
>>>> Attached is a rebased patch, addressing most of the remaining issues.
>>>>
>>>
>>> It appears that on the apply side, the patch always creates a new
>>> relfilenode irrespective of whether the sequence message is
>>> transactional or not. Is it required to create a new relfilenode for
>>> non-transactional messages? If not that could be costly?
>>>
>>
>>
>> That's a good catch, I think we should just write the page in the non-transactional case, no need to mess with relnodes.
>>
>
> What if the current node has also incremented from the existing
> sequence? Basically, how will we deal with conflicts? It seems we will
> overwrite the actions done on the existing node which means sequence
> values can go back.
>
I think this is perfectly acceptable behavior, we are replicating state from upstream, not reconciling state on downstream.
You can't really use the builtin sequences to implement distributed sequence via replication. If user wants to write to both nodes they should not replicate the sequence value and instead offset the sequence on each node so they produce different ranges, that's quite common approach. One day we might want revisit adding support for custom sequence AMs.
> * Currently, the patch uses one sync worker per sequence. It seems to
> be a waste of resources considering apart from one additional process,
> we need origin/slot to sync each sequence.
>
This is indeed wasteful but not something that I'd consider blocker for the patch personally.
--
Petr
view thread (113+ 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]
Subject: Re: logical decoding and replication of sequences
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