Re: BUG #17983: Assert IsTransactionState() failed when empty string statement prepared in aborted transaction
От | Japin Li |
---|---|
Тема | Re: BUG #17983: Assert IsTransactionState() failed when empty string statement prepared in aborted transaction |
Дата | |
Msg-id | MEYP282MB16694FA5DA0442708310344DB65DA@MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM обсуждение исходный текст |
Ответ на | Re: BUG #17983: Assert IsTransactionState() failed when empty string statement prepared in aborted transaction (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-bugs |
On Wed, 21 Jun 2023 at 00:32, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Japin Li <japinli@hotmail.com> writes: >> Yeah, SearchSysCache1() need in an transaction block, here is a patch >> fixed it. > > I'm not sure if anyone out there is expecting that this case should > work, but it probably did work at one time. Rather than throwing > an error, it'd be better to fix plancache.c so it doesn't fail. > I looked at the code and found that that's pretty much a one-line > fix, because there are already code paths that avoid doing anything > extra for transaction control commands (e.g ROLLBACK, which'd > otherwise have this same issue). Agreed, it's much better than throwing an error. LGTM. >> Another question, why should we need to create a plan cache entry for >> empty input? > > Well, we have to have something to support the wire protocol behavior > for this case. No doubt we could hack up postgres.c to handle it > without a plan cache entry, but it'd be far more invasive to do it > there. > Thanks for your explanation! Got it. -- Regrads, Japin Li.
В списке pgsql-bugs по дате отправления: