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

From Greg Nancarrow
Subject Re: Parallel scan with SubTransGetTopmostTransaction assert coredump
Date
Msg-id CAJcOf-d49cHMumokFr5qKkG8=7Z79h+6JbG8dKXRKfhuzvQ_Lg@mail.gmail.com
Whole thread Raw
In response to Re: Parallel scan with SubTransGetTopmostTransaction assert coredump  ("houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>)
List pgsql-hackers
On Tue, May 18, 2021 at 9:41 PM houzj.fnst@fujitsu.com
<houzj.fnst@fujitsu.com> wrote:
>
> > To: Pengchengliu <pengchengliu@tju.edu.cn>
> > Cc: Greg Nancarrow <gregn4422@gmail.com>; Andres Freund <andres@anarazel.de>; PostgreSQL-development
<pgsql-hackers@postgresql.org>
> > Subject: Re: Re: Parallel scan with SubTransGetTopmostTransaction assert coredump
>
> > I've also seen the reports of the same Assert(TransactionIdFollowsOrEquals(xid, TransactionXmin)) with a subsequent
crashin a parallel worker in PostgreSQL v11-based
 
> > build, Though I was unable to investigate deeper and reproduce the issue. The details above in the thread make me
thinkit is a real and long-time-persistent error that is
 
> > surely worth to be fixed.
>
> I followed Liu's reproduce steps and successfully reproduce it in about half an hour running.
> My compile option is : " ./configure --enable-cassert --prefix=/home/pgsql".
>
> After applying greg-san's change, the coredump did not happened in two hour(it is still running).
> Note, I have not taken a deep look into the change, just provide some test information in advance.
>

+1
Thanks for doing that.
I'm unsure if that "fix" is the right approach, so please investigate it too.

Regards,
Greg Nancarrow
Fujitsu Australia



pgsql-hackers by date:

Previous
From: Chapman Flack
Date:
Subject: Re: allow specifying direct role membership in pg_hba.conf
Next
From: Ashutosh Bapat
Date:
Subject: Re: postgres_fdw - should we tighten up batch_size, fetch_size options against non-numeric values?