From: "Pengchengliu" <pengchengliu@tju.edu.cn>
To: <rhaas@postgresql.org>,
	<tgl@sss.pgh.pa.us>
Cc: "'Andres Freund'" <andres@anarazel.de>,
	"'PostgreSQL-development'" <pgsql-hackers@postgresql.org>,
	"'Greg Nancarrow'" <gregn4422@gmail.com>
References: 
 <AGAApwBuDke9jEHtVdrbtaq-.1.1620293412680.Hmail.2008202116@tju.edu.cn>
 <000901d742f1$acae3ad0$060ab070$@tju.edu.cn>
 <20210507035510.he7e5hiu6dsi4rug@alap3.anarazel.de>
 <000001d7432b$33cc4a00$9b64de00$@tju.edu.cn>
 <000601d74604$d8af7570$8a0e6050$@tju.edu.cn>
 <CAJcOf-fcVo39cUHvyddvUHx6i_Tkfm5JwpDXx_o=VyXo2U6C_Q@mail.gmail.com>
 <002501d74796$ce4083c0$6ac18b40$@tju.edu.cn>
 <CAJcOf-f4C7s-dFagXCM1x9sTecO6qsZyyoNbWg7U60EA2KyM7Q@mail.gmail.com>
 <000601d74868$4cacca30$e6065e90$@tju.edu.cn>
 <CAJcOf-ebgfWeAqDFQfwRN=h49VzkjPunR0TvkY8nax9c1e2szw@mail.gmail.com>
 <002f01d748ac$eaa781a0$bff684e0$@tju.edu.cn>
 <CAJcOf-cJfLcgxwz8TeTZqWe3z2XdLkZAT8gHTwgHqHP9-Cb-Mw@mail.gmail.com>
In-Reply-To: 
 <CAJcOf-cJfLcgxwz8TeTZqWe3z2XdLkZAT8gHTwgHqHP9-Cb-Mw@mail.gmail.com>
Subject: RE: Parallel scan with SubTransGetTopmostTransaction assert coredump
Date: Mon, 17 May 2021 19:18:05 +0800
Message-ID: <001a01d74b0e$4ef03770$ecd0a650$@tju.edu.cn>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: 
 AQJWZzOrsYDN3Ar+nCJfWwrfcv+5KQKg04GwAjPEpnoBa3FGLQFfmMneAjZdCbACx8BMQwIzciSwAk3xh68DTHSB3wKOgpNZAoxWcXapHRpPUA==
Content-Language: zh-cn
Archived-At: 
 <https://www.postgresql.org/message-id/001a01d74b0e%244ef03770%24ecd0a650%24%40tju.edu.cn>
Precedence: bulk

Hi Tom & Robert,
  Could you review this Assert(TransactionIdFollowsOrEquals(xid, =
TransactionXmin)) in SubTransGetTopmostTransaction.=20
  I think this assert is unsuitable for parallel work process.

 Before we discuss it in=20
  =
https://www.postgresql-archive.org/Parallel-scan-with-SubTransGetTopmostT=
ransaction-assert-coredump-td6197408.html
=20
Thanks
Pengcheng

-----Original Message-----
From: Greg Nancarrow <gregn4422@gmail.com>=20
Sent: 2021=E5=B9=B45=E6=9C=8815=E6=97=A5 0:44
To: Pengchengliu <pengchengliu@tju.edu.cn>
Cc: Andres Freund <andres@anarazel.de>; PostgreSQL-development =
<pgsql-hackers@postgresql.org>
Subject: Re: Parallel scan with SubTransGetTopmostTransaction assert =
coredump

On Fri, May 14, 2021 at 8:36 PM Pengchengliu <pengchengliu@tju.edu.cn> =
wrote:
>   Did you use pgbench with the script sub_120.sql which I provide in =
attachment?

yes

>
>   Did you increase the number PGPROC_MAX_CACHED_SUBXIDS? Please don't =
change any codes, now we just use the origin codes in PG13.2.
>

No, I have made no source code changes at all.
That was my suggestion, for you to try - because if the problem is =
avoided by increasing PGPROC_MAX_CACHED_SUBXIDS (to say 128) then it =
probably indicates the overflow condition is affecting the xmin.xmax of =
the two snapshots such that it invalidates the condition that is =
asserted.


I think one problem is that in your settings, you haven't set =
"max_worker_processes", yet have set "max_parallel_workers =3D 128".
I'm finding no more than 8 parallel workers are actually active at any =
one time.
On top of this, you've got pgbench running with 200 concurrent clients.
So many queries are actually executing parallel plans without using =
parallel workers, as the workers can't actually be launched (and this is =
probably why I'm finding it hard to reproduce the issue, if the problem =
involves snapshot suboverflow and parallel workers).
I find that the following settings improve the parallelism per query and =
the whole test runs very much faster:

max_connections =3D 2000
parallel_setup_cost=3D0
parallel_tuple_cost=3D0
min_parallel_table_scan_size=3D0
max_parallel_workers_per_gather=3D4
max_parallel_workers =3D 100
max_worker_processes =3D 128

and adjust the pgbench command-line:   pgbench  -d postgres -p 33550
-n -r -f sub_120.sql   -c 25 -j 25 -T 1800

Problem is, I still get no coredump when using this.
Can you try these settings and let me know if the crash still happens if =
you use these settings?

I also tried:

max_connections =3D 2000
parallel_setup_cost=3D0
parallel_tuple_cost=3D0
min_parallel_table_scan_size=3D0
max_parallel_workers_per_gather=3D2
max_parallel_workers =3D 280
max_worker_processes =3D 300

and the pgbench command-line:   pgbench  -d postgres -p 33550  -n -r
-f sub_120.sql   -c 140 -j 140 -T 1800

- but I still get no coredump.

Regards,
Greg Nancarrow
Fujitsu Australia