Message-ID: <102cb85d-2205-c8ec-ac37-797c03e025e1@gmail.com>
Date: Tue, 23 May 2023 14:00:00 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.4.2
Subject: Re: BUG #17695: Failed Assert in logical replication snapbuild.
Content-Language: en-US
To: Masahiko Sawada <sawada.mshk@gmail.com>
Cc: Daniel Gustafsson <daniel@yesql.se>, bowenshi <zxwsbg@qq.com>,
 "pgsql-bugs@lists.postgresql.org" <pgsql-bugs@lists.postgresql.org>
References: <17695-6be9277c9295985f@postgresql.org>
 <CAD21AoCsxvV3Mpzv8Q3hG7CdQZ7vSBWyEFLgY3QZARRDcgzVwA@mail.gmail.com>
 <tencent_7EB71DA5D7BA00EB0B429DCE45D0452B6406@qq.com>
 <CAD21AoAofY33TOdvJ_FHAob8C+H4gKOrnK_V+p3XzEMPQO24Cg@mail.gmail.com>
 <DB7F9F38-11F6-4EA2-B414-5BD925A1FE25@yesql.se>
 <CAD21AoDNv09ZMr-E+fNzhduvkE6eK2fjCRA7wJHOhF8APH5JdQ@mail.gmail.com>
 <7e4d4a80-3e3c-231f-f886-6cada2aa582b@gmail.com>
 <CAD21AoDyE91TroZQOtSyjq-k9KmUOHTfUe1mG7kFLDCLTHNH_A@mail.gmail.com>
From: Alexander Lakhin <exclusion@gmail.com>
In-Reply-To: 
 <CAD21AoDyE91TroZQOtSyjq-k9KmUOHTfUe1mG7kFLDCLTHNH_A@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/102cb85d-2205-c8ec-ac37-797c03e025e1%40gmail.com>
Precedence: bulk

22.05.2023 03:56, Masahiko Sawada wrote:
> On Thu, May 18, 2023 at 11:00 PM Alexander Lakhin <exclusion@gmail.com> wrote:
>
>> I can easily (without gdb and sleep()) reproduce the issue on master with
>> the following script:
>> ...
> Thank you for sharing the script. But it seems not stable as I could
> not reproduce the issue in my environment. I think we need a stable
> reproducer so that we can include it in core regression tests. Or it
> may be okay not to include it if we could not find a convenient way
> and the fix is trivial.

I've came to the minimal reproducer:
numclients=40
for ((c=1;c<=numclients;c++)); do
createdb regress_$c
done

for ((c=1;c<=numclients;c++)); do
(
echo "
CREATE TABLE replication_example(id SERIAL PRIMARY KEY, somedata int, text varchar(120));
SELECT 'init' FROM pg_create_logical_replication_slot('regression_slot_$c', 'test_decoding');
SELECT data FROM pg_logical_slot_get_changes('regression_slot_$c', NULL, NULL, 'include-xids', '0', 'skip-empty-xacts', 
'1');
" | psql -d regress_$c >psql-$c.log
) &
done
wait
grep TRAP server.log

(I've set
fsync = off
wal_level = logical
in postgresql.conf)

When using a build made with ASAN (and gcc-12), I get several asserts at once:
grep TRAP server.log  | wc -l
12
Without ASAN, I get no failures with numclients = 40, but still get series of
those with numclients=80...

It's hardly suitable for the regression test, but it clearly demonstrates the
issue without using gdb. With the fix from [1] applied, I've got no failures,
even with numclients=100, for 10 runs.

I also think, that the fix is simple enough to be committed without a
complicated/resource-intensive regression test.

[1] https://www.postgresql.org/message-id/CAD21AoDNv09ZMr-E%2BfNzhduvkE6eK2fjCRA7wJHOhF8APH5JdQ%40mail.gmail.com

Best regards,
Alexander