RE: Parallel scan with SubTransGetTopmostTransaction assert coredump

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 <andres(at)anarazel(dot)de>
Sent: 2021年5月7日 11:55
To: Pengchengliu <pengchengliu(at)tju(dot)edu(dot)cn>
Cc: pgsql-hackers(at)postgresql(dot)org
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