Re: [PATCH] plpython function causes server panic
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Hao Zhang <zhrt1446384557@gmail.com>, Andres Freund <andres@anarazel.de>, pgsql-hackers@lists.postgresql.org
Date: 2024-03-22T18:02:40Z
Lists: pgsql-hackers
On Fri, Mar 22, 2024 at 1:52 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: > > I agree with the general direction. A few comments: > > > - Isn't it redundant to test if IsInParallelMode() || > > IsParallelWorker()? We can't be in a parallel worker without also > > being in parallel mode, except during the worker startup sequence. > > Hmm. The existing code in AssignTransactionId and > CommandCounterIncrement tests both, so I figured that the conservative > course was to make DefineSavepoint and friends test both. Are you > saying AssignTransactionId and CommandCounterIncrement are wrong? > If you're saying you don't believe that these routines are reachable > during parallel worker start, that could be true, but I'm not sure > I want to make that assumption. In any case, surely the xxxSavepoint > routines are not hot enough to make it an interesting > micro-optimization. (Perhaps it is worthwhile in AssignTransactionId > and CCI, but changing those seems like a job for another patch.) Yeah, that's all fair enough. I went back and looked at the history of this and found 94b4f7e2a635c3027a23b07086f740615b56aa64. -- Robert Haas EDB: http://www.enterprisedb.com
Commits
-
Allow "internal" subtransactions in parallel mode.
- 0075d78947e3 17.0 landed
-
Tighten up application of parallel mode checks.
- 94b4f7e2a635 9.6.0 cited