Re: BUG #17983: Assert IsTransactionState() failed when empty string statement prepared in aborted transaction
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Japin Li <japinli@hotmail.com>
Cc: exclusion@gmail.com, pgsql-bugs@lists.postgresql.org
Date: 2023-06-20T16:32:27Z
Lists: pgsql-bugs
Attachments
- dont-fail-on-preparing-empty-statement.patch (text/x-diff) patch
Japin Li <japinli@hotmail.com> writes: > On Tue, 20 Jun 2023 at 03:00, PG Bug reporting form <noreply@postgresql.org> wrote: >> The following psql script: >> BEGIN; >> ERROR; >> ; >> \gdesc >> triggers an assertion failure with the following stack trace: >> so maybe an empty input string is not legal for creating a cached plan >> when the transaction is aborted? > 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). We just need to make a NULL parsetree use those paths. > 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. regards, tom lane
Commits
-
Avoid Assert failure when processing empty statement in aborted xact.
- 555b929bbe7b 16.0 landed
- d1fc0f382da1 13.12 landed
- cb74f7bec64f 15.4 landed
- a98a040056c1 12.16 landed
- a8be2356c556 11.21 landed
- 120ea65b8a0c 14.9 landed