Re: Parallel scan with SubTransGetTopmostTransaction assert coredump
Greg Nancarrow <gregn4422@gmail.com>
From: Greg Nancarrow <gregn4422@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Pavel Borisov <pashkin.elfe@gmail.com>,
Tomas Vondra <tomas.vondra@enterprisedb.com>, Maxim Orlov <m.orlov@postgrespro.ru>, Michael Paquier <michael@paquier.xyz>, Pengchengliu <pengchengliu@tju.edu.cn>, Andres Freund <andres@anarazel.de>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2021-08-04T03:41:11Z
Lists: pgsql-hackers
Attachments
- v6-0001-RH-Fix-parallel-worker-failed-assertion-and-coredump.patch (application/octet-stream) patch v6-0001
On Wed, Aug 4, 2021 at 3:21 AM Robert Haas <robertmhaas@gmail.com> wrote: > >The idea I sort of had floating around in my mind is a little >different than what Greg has implemented. I was thinking that we could >just skip SerializeSnapshot and the corresponding shm_toc_allocate() >if !IsolationUsesXactSnapshot(). Then on the restore side we could >just call shm_toc_lookup() with noError = true and skip >RestoreTransactionSnapshot/RestoreSnapshot if it returns NULL. I've tried to follow your description and have attached a patch to hopefully match it, but it doesn't pass "make check-world". Perhaps I messed something up (apologies if so), or additional changes are needed to match what you had in mind or correct additional issues you didn't foresee? t/001_pgbench_with_server.pl .. 10/? # Failed test 'pgbench scale 1 initialization status (got 1 vs expected 0)' # at t/001_pgbench_with_server.pl line 108. ... # creating primary keys... # pgbench: fatal: query failed: ERROR: cannot take query snapshot during a parallel operation # CONTEXT: parallel worker # pgbench: query was: alter table pgbench_accounts add primary key (aid) >I don't know why Greg's patch is changing anything related to the >active snapshot (as opposed to the transaction snapshot). Maybe >there's a reason why we need that change, but I don't know what it is. I don't think my v2/v5 patch is changing anything related to the active snapshot (is it?). It's restoring the serialized active snapshot, installing it as the transaction snapshot and setting it as the active snapshot. The patch removes the additionally-acquired transaction snapshot in InitializeParallelDSM (which seems like a later snapshot to that which is actually being used in the execution state for the statement, back in the leader, if I recall correctly). Basically, in the parallel workers, I've tried to match the snapshot setup to that used in the leader. If the v2/v5 patch doesn't work correctly for some isolation level, I've yet to find it (but can't absolutely rule out there's some case not accounted for). Regards, Greg Nancarrow Fujitsu Australia
Commits
-
Fix broken snapshot handling in parallel workers.
- 96f6ef9fe451 10.19 landed
- 198cf81e2c64 11.14 landed
- f4b77e82ebf4 12.9 landed
- bc062cb93823 13.5 landed
- 11c1239881b3 14.0 landed
- a780b2fcce6c 15.0 landed
-
Doc: move some catalogs.sgml entries to the right place.
- 713a431c781f 14.0 cited
-
Stamp 13.2.
- 3fb4c75e857a 13.2 cited
-
Create an infrastructure for parallel computation in PostgreSQL.
- 924bcf4f16d5 9.5.0 cited