Message-ID: <797df1d7-9b35-42c7-4787-4665fcd1252f@enterprisedb.com>
Date: Thu, 16 Dec 2021 15:54:30 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.2.0
Subject: Re: logical decoding and replication of sequences
Content-Language: en-US
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>,
 PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
 Petr Jelinek <petr.jelinek@enterprisedb.com>
References: <d045f3c2-6cfb-06d3-5540-e63c320df8bc@enterprisedb.com>
 <3005299b-267d-8e4a-68a3-abdad3e96aba@enterprisedb.com>
 <3d6df331-5532-6848-eb45-344b265e0238@enterprisedb.com>
 <482c10c1-b110-819f-b0e7-17549fa2f0dc@enterprisedb.com>
 <12a9ecd6-4edb-a367-33da-4e2d03b0aace@enterprisedb.com>
 <CAMT0RQQeDR51xs8zTa25YpfKB1B34nS-Q4hhsRPznVsjMB_P1w@mail.gmail.com>
 <bdc688ef-9339-8234-d786-409f1e603711@enterprisedb.com>
 <e6ef8862-31e4-1582-9274-f8f57b7f1cab@enterprisedb.com>
 <2cd38bab-c874-8e0b-98e7-d9abaaf9806a@enterprisedb.com>
 <c0bd317a-fef5-9ef9-66be-a10eae686b96@enterprisedb.com>
 <118b249f-e4ef-2faf-8e25-dd25236dc964@enterprisedb.com>
 <d0e077e9-6440-fcf5-6b8a-b2a32be408e1@enterprisedb.com>
 <ae3cab67-c31e-b527-dd73-08f196999ad4@enterprisedb.com>
 <CAA4eK1J5R=3H1kdt4B0-K6A=7PoELdOW23HpYaTXQfE0y4p6KQ@mail.gmail.com>
 <f5cc848c-633d-09a7-5d99-3c9cf95da7a7@enterprisedb.com>
 <CAA4eK1+m0qEziKSFy4AD2HBj=i+Jocm=-=zhi9N1ESwy7mQ3nA@mail.gmail.com>
From: Tomas Vondra <tomas.vondra@enterprisedb.com>
In-Reply-To: 
 <CAA4eK1+m0qEziKSFy4AD2HBj=i+Jocm=-=zhi9N1ESwy7mQ3nA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/797df1d7-9b35-42c7-4787-4665fcd1252f%40enterprisedb.com>
Precedence: bulk


On 12/16/21 12:59, Amit Kapila wrote:
> On Wed, Dec 15, 2021 at 7:21 PM Tomas Vondra
> <tomas.vondra@enterprisedb.com> wrote:
>>
>> On 12/15/21 14:20, Amit Kapila wrote:
>>> On Tue, Dec 14, 2021 at 7:02 AM Tomas Vondra
>>> <tomas.vondra@enterprisedb.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> here's an updated version of the patches, dealing with almost all of the
>>>> issues (at least in the 0001 and 0002 parts). The main changes:
>>>>
>>>> 1) I've removed the  'created' flag from fill_seq_with_data, as
>>>> discussed. I don't think it's needed by any of the parts (not even 0003,
>>>> AFAICS). We still need it in xl_seq_rec, though.
>>>>
>>>> 2) GetCurrentTransactionId() added to sequence.c are called only with
>>>> wal_level=logical, to minimize the overhead.
>>>>
>>>>
>>>> There's still one remaining problem, that I already explained in [1].
>>>> The problem is that with this:
>>>>
>>>>   BEGIN;
>>>>   SELECT nextval('s') FROM generate_series(1,100);
>>>>   ROLLBACK;
>>>>
>>>>
>>>> The root cause is that pg_current_wal_lsn() uses the LogwrtResult.Write,
>>>> which is updated by XLogFlush() - but only in RecordTransactionCommit.
>>>> Which makes sense, because only the committed stuff is "visible".
>>>>
>>>> But the non-transactional behavior of sequence decoding disagrees with
>>>> this, because now some of the changes from aborted transactions may be
>>>> replicated. Which means the wait_for_catchup() ends up not waiting for
>>>> the sequence change to be replicated. This is an issue for tests in
>>>> patch 0003, at least.
>>>>
>>>> My concern is this actually affects other places waiting for things
>>>> getting replicated :-/
>>>>
>>>
>>> By any chance, will this impact synchronous replication as well which
>>> waits for commits to be replicated?
>>>
>>
>> Physical or logical replication?
>>
> 
> logical replication.
> 
>> Physical is certainly not replicated.
>>
>> For logical replication, it's more complicated.
>>
>>> How is this patch dealing with prepared transaction case where at
>>> prepare we will send transactional changes and then later if rollback
>>> prepared happens then the publisher will rollback changes related to
>>> new relfilenode but subscriber would have already replayed the updated
>>> seqval change which won't be rolled back?
>>>
>>
>> I'm not sure what exact scenario you are describing, but in general we
>> don't rollback sequence changes anyway, so this should not cause any
>> divergence between the publisher and subscriber.
>>
>> Or are you talking about something like ALTER SEQUENCE? I think that
>> should trigger the transactional behavior for the new relfilenode, so
>> the subscriber won't see that changes.
>>
> 
> Yeah, something like Alter Sequence and nextval combination. I see
> that it will be handled because of the transactional behavior for the
> new relfilenode as for applying each sequence change, a new
> relfilenode is created.

Right.

> I think on apply side, the patch always creates a new relfilenode
> irrespective of whether the sequence message is transactional or not.
> Do we need to do that for the non-transactional messages as well?
> 

Good question. I don't think that's necessary, I'll see if we can simply
update the tuple (mostly just like redo).

regards

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company