From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
cc: Hao Zhang <zhrt1446384557@gmail.com>, pgsql-hackers@lists.postgresql.org
Subject: Re: [PATCH] plpython function causes server panic
In-reply-to: <301509.1701479055@sss.pgh.pa.us>
References: <CALY6Dr-2yLVeVPhNMhuBnRgOZo1UjoTETgtKBx1B2gUi8yy+3g@mail.gmail.com> <301509.1701479055@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Fri, 01 Dec 2023 20:04:15 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <307440.1701481871.1@sss.pgh.pa.us>
Date: Fri, 01 Dec 2023 20:51:11 -0500
Message-ID: <307441.1701481871@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/307441.1701481871%40sss.pgh.pa.us>
Precedence: bulk

I wrote:
> The only readily-reachable error case in BeginInternalSubTransaction
> is this specific one about IsInParallelMode, which was added later
> than the original design and evidently with not a lot of thought or
> testing.  The comment for it speculates about whether we could get
> rid of it, so I wonder if our thoughts about this ought to go in that
> direction.

After thinking a bit more I wonder why we need that error check at all.
Why isn't it sufficient to rely on GetNewTransactionId()'s check that
throws an error if a parallelized subtransaction tries to obtain an XID?
I don't see why we'd need to "synchronize transaction state" about
anything that never acquires an XID.

			regards, tom lane