Message-ID: <352ee4b9-ae44-0640-71c3-edca97b89036@enterprisedb.com>
Date: Mon, 7 Mar 2022 22:11:19 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.5.0
Subject: Re: logical decoding and replication of sequences
Content-Language: en-US
From: Tomas Vondra <tomas.vondra@enterprisedb.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>,
 Petr Jelinek <petr.jelinek@enterprisedb.com>,
 PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
References: <d045f3c2-6cfb-06d3-5540-e63c320df8bc@enterprisedb.com>
 <CAA4eK1J5R=3H1kdt4B0-K6A=7PoELdOW23HpYaTXQfE0y4p6KQ@mail.gmail.com>
 <f5cc848c-633d-09a7-5d99-3c9cf95da7a7@enterprisedb.com>
 <90b4e402-3f07-14f4-deca-5eaca31f70a3@enterprisedb.com>
 <de7e9856-b49f-67bd-2ade-447f2d2cbc4b@enterprisedb.com>
 <22aef14d-0ea1-9044-c2e7-29f88762eaec@enterprisedb.com>
 <32540e16-fab6-f790-b99b-5a8fca8bde52@enterprisedb.com>
 <3B014BE4-EE61-4834-8FF6-937B43C46BC7@enterprisedb.com>
 <3d68b45a-ceb5-6824-3a39-f53411fd0c88@enterprisedb.com>
 <802f8b1b-a798-be52-c829-7f0fb9faafd5@enterprisedb.com>
 <983bf0c7-9757-fd13-3896-8452cf4c4c52@enterprisedb.com>
 <9211312a-6501-1caf-ee7b-c0d4814b6091@enterprisedb.com>
 <41ada110-bc7c-32a3-08bd-fb5023dd74ba@enterprisedb.com>
 <CAA4eK1Kp8sh=zQB=Jzpnnqu4xAsLM6ha7+bsBKNDroyJY81aCw@mail.gmail.com>
 <CAA4eK1KGn6cQqJEsubOOENwQOANsExiV2sKL52r4U10J8NJEMQ@mail.gmail.com>
 <b38fb589-d529-af4a-36a0-8d47c2055fcb@enterprisedb.com>
In-Reply-To: <b38fb589-d529-af4a-36a0-8d47c2055fcb@enterprisedb.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: <https://www.postgresql.org/message-id/352ee4b9-ae44-0640-71c3-edca97b89036%40enterprisedb.com>
Precedence: bulk


On 3/7/22 17:39, Tomas Vondra wrote:
> 
> 
> On 3/1/22 12:53, Amit Kapila wrote:
>> On Mon, Feb 28, 2022 at 5:16 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>>>
>>> On Sat, Feb 12, 2022 at 6:04 AM Tomas Vondra
>>> <tomas.vondra@enterprisedb.com> wrote:
>>>>
>>>> On 2/10/22 19:17, Tomas Vondra wrote:
>>>>> I've polished & pushed the first part adding sequence decoding
>>>>> infrastructure etc. Attached are the two remaining parts.
>>>>>
>>>>> I plan to wait a day or two and then push the test_decoding part. The
>>>>> last part (for built-in replication) will need more work and maybe
>>>>> rethinking the grammar etc.
>>>>>
>>>>
>>>> I've pushed the second part, adding sequences to test_decoding.
>>>>
>>>
>>> The test_decoding is failing randomly in the last few days. I am not
>>> completely sure but they might be related to this work. The two of
>>> these appears to be due to the same reason:
>>> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink&dt=2022-02-25%2018%3A50%3A09
>>> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=locust&dt=2022-02-17%2015%3A17%3A07
>>>
>>> TRAP: FailedAssertion("prev_first_lsn < cur_txn->first_lsn", File:
>>> "reorderbuffer.c", Line: 1173, PID: 35013)
>>> 0   postgres                            0x00593de0 ExceptionalCondition + 160\\0
>>>
>>
>> While reviewing the code for this, I noticed that in
>> sequence_decode(), we don't call ReorderBufferProcessXid to register
>> the first known lsn in WAL for the current xid. The similar functions
>> logicalmsg_decode() or heap_decode() do call ReorderBufferProcessXid
>> even if they decide not to queue or send the change. Is there a reason
>> for not doing the same here? However, I am not able to deduce any
>> scenario where lack of this will lead to such an Assertion failure.
>> Any thoughts?
>>
> 
> Thanks, that seems like an omission. Will fix.
> 

I've pushed this simple fix. Not sure it'll fix the assert failures on
skink/locust, though. Given the lack of information it'll be difficult
to verify. So let's wait a bit.


regards

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