Re: [PATCH] plpython function causes server panic
От | Robert Haas |
---|---|
Тема | Re: [PATCH] plpython function causes server panic |
Дата | |
Msg-id | CA+TgmoZ4jb1UY7B8hqbz+7hdAxK5Sd95VpwsueJjwWT65sReww@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PATCH] plpython function causes server panic (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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
В списке pgsql-hackers по дате отправления: