pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Pengchengliu <pengchengliu@tju.edu.cn>
To: rhaas@postgresql.org
To: tgl@sss.pgh.pa.us
Cc: 'Andres Freund' <andres@anarazel.de>
Cc: 'PostgreSQL-development' <pgsql-hackers@postgresql.org>
Cc: 'Greg Nancarrow' <gregn4422@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> (raw)
In-Reply-To: <CAJcOf-cJfLcgxwz8TeTZqWe3z2XdLkZAT8gHTwgHqHP9-Cb-Mw@mail.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>

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

 Before we discuss it in 
  https://www.postgresql-archive.org/Parallel-scan-with-SubTransGetTopmostTransaction-assert-coredump-...
 
Thanks
Pengcheng

-----Original Message-----
From: Greg Nancarrow <gregn4422@gmail.com> 
Sent: 2021年5月15日 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 = 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 = 2000
parallel_setup_cost=0
parallel_tuple_cost=0
min_parallel_table_scan_size=0
max_parallel_workers_per_gather=4
max_parallel_workers = 100
max_worker_processes = 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 = 2000
parallel_setup_cost=0
parallel_tuple_cost=0
min_parallel_table_scan_size=0
max_parallel_workers_per_gather=2
max_parallel_workers = 280
max_worker_processes = 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





view thread (62+ messages)  latest in thread

Message-ID: <001a01d74b0e$4ef03770$ecd0a650$@tju.edu.cn>
Permalink:  ../001a01d74b0e$4ef03770$ecd0a650$@tju.edu.cn/
Also on:    postgresql.org/message-id/001a01d74b0e$4ef03770$ecd0a650$@tju.edu.cn

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: pengchengliu@tju.edu.cn, rhaas@postgresql.org, tgl@sss.pgh.pa.us, andres@anarazel.de, gregn4422@gmail.com
  Subject: RE: Parallel scan with SubTransGetTopmostTransaction assert coredump
  In-Reply-To: <001a01d74b0e$4ef03770$ecd0a650$@tju.edu.cn>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox