Horton

Re: Re: Parallel scan with SubTransGetTopmostTransaction assert coredump

Pavel Borisov <pashkin.elfe@gmail.com>

View thread View on postgr.es
From: Pavel Borisov <pashkin.elfe@gmail.com>
To: Greg Nancarrow <gregn4422@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>, Pengchengliu <pengchengliu@tju.edu.cn>, Andres Freund <andres@anarazel.de>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2021-05-24T13:55:51Z
Lists: pgsql-hackers

Attachments

пн, 24 мая 2021 г. в 09:22, Greg Nancarrow <gregn4422@gmail.com>:

> On Mon, May 24, 2021 at 2:50 PM Michael Paquier <michael@paquier.xyz>
> wrote:
> >
> > On Mon, May 24, 2021 at 12:04:37PM +1000, Greg Nancarrow wrote:
> > > Keep cfbot happy, use the PG14 patch as latest.
> >
> > This stuff is usually very tricky.
>
> Agreed. That's why I was looking for experts in this snapshot-handling
> code, to look closer at this issue, check my proposed fix, come up
> with a better solution etc.
>
> >Do we have a way to reliably
> > reproduce the report discussed here?
>

Using a recipe similar to what has been described above in the thread, I
reliably reproduced the bug in many Postgres versions. (v.11, v.13 etc.).
1. Make & make install
2. Make check
3. run  SubTransGetTopmostTransaction-rep.sh in the Postgres source code
dir.

The test fails with coredumps in around 10 minutes. With applied fix has
never failed yet.
(Though transaction snapshots kitchen is indeed tricky and I am not 100%
sure the fix does right thing which is safe in all circumstances)

Commits

  1. Fix broken snapshot handling in parallel workers.

  2. Doc: move some catalogs.sgml entries to the right place.

  3. Stamp 13.2.

  4. Create an infrastructure for parallel computation in PostgreSQL.