Hi Andres, Reproduce steps. 1, Modify and adjust NUM_SUBTRANS_BUFFERS to 128 from 32 in the file "src/include/access/subtrans.h" line number 15. 2, configure with enable assert and build it. 3, init a new database cluster. 4, modify postgres.conf and add some parameters as below. As the coredump from parallel scan, so we adjust parallel setting, make it easy to reproduce.
max_connections = 2000
parallel_setup_cost=0
parallel_tuple_cost=0
min_parallel_table_scan_size=0
max_parallel_workers_per_gather=8
max_parallel_workers = 32
5, start the database cluster.
6, use the script init_test.sql in attachment to create tables.
7, use pgbench with script sub_120.sql in attachment to test it. Try it
sometimes, you should get the coredump file.
pgbench -d postgres -p 33550 -n -r -f sub_120.sql -c 200 -j 200 -T 120
Thanks
Pengcheng
-----Original Message-----
From: Andres Freund <[email protected]>
Sent: 2021年5月7日 11:55
To: Pengchengliu <[email protected]>
Cc: [email protected]
Subject: Re: Parallel scan with SubTransGetTopmostTransaction assert coredump
Hi,
On 2021-05-07 11:32:57 +0800, Pengchengliu wrote:
> Hi Hackers，
>
> Last email, format error, missing some information, so I resend this email.
>
> With PG 13.2(3fb4c75e857adee3da4386e947ba58a75f3e74b7), I tested
> subtransaction with parallel scan, I got a subtransaction coredump as below:
> So the root cause is the Parallel Workers process set the TransactionXmin
> with later transcation snapshot. When parallel scan, Parallel Workers process
> use the older active snapshot.
>
> It leads to subtrans assert coredump. I don't know how to fix it. Is there
> any ideas?
Do you have steps to reliably reproduce this?
Greetings,
Andres Freund
test_script.tar
Description: Unix tar archive
