Re: Re: Parallel scan with SubTransGetTopmostTransaction assert coredump - Mailing list pgsql-hackers

From Pavel Borisov
Subject Re: Re: Parallel scan with SubTransGetTopmostTransaction assert coredump
Date
Msg-id CALT9ZEG4vzW1C=U4-AvgCA9=QEqVfrxaQ8PQ98CGNZ5LBG96kQ@mail.gmail.com
Whole thread Raw
In response to Re: Re: Parallel scan with SubTransGetTopmostTransaction assert coredump  (Greg Nancarrow <gregn4422@gmail.com>)
Responses Re: Re: Parallel scan with SubTransGetTopmostTransaction assert coredump  (Greg Nancarrow <gregn4422@gmail.com>)
List pgsql-hackers


пн, 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)

Attachment

pgsql-hackers by date:

Previous
From: Guillaume Lelarge
Date:
Subject: Issue on catalogs.sgml
Next
From: Aleksander Alekseev
Date:
Subject: Re: rand48 replacement