pg.ddx.io pgsql-bugs@postgresql.org mailing list archive
help / color / mirror / Atom feedBUG #17702: An assert failed in parse_utilcmd.c
5+ messages / 3 participants
[nested] [flat]
Commits from this thread:
2022-11-29 8b47ccb624 5dfc2b753b 7715a3c244 Prevent clobbering of utility statements in SQL function caches.
* BUG #17702: An assert failed in parse_utilcmd.c
@ 2022-11-29 02:45 PG Bug reporting form <noreply@postgresql.org>
0 siblings, 1 reply; 5+ messages in thread
From: PG Bug reporting form @ 2022-11-29 02:45 UTC (permalink / raw)
To: pgsql-bugs@lists.postgresql.org; +Cc: xinwen@stu.scu.edu.cn
The following bug has been logged on the website:
Bug reference: 17702
Logged by: xin wen
Email address: xinwen@stu.scu.edu.cn
PostgreSQL version: 15.1
Operating system: Ubuntu 20.04
Description:
When executing the following query:
CREATE FUNCTION function0 () RETURNS INT LANGUAGE SQL AS $$ CREATE TABLE
table1 ( column0 INT CHECK ( 'x' = 'x' )) ; SELECT 1 ; $$ ;
SELECT function0 () FROM ( VALUES ( 1 ) , ( 1 ) ) AS alias0;
I get a failed assertion with the following stacktrace:
Core was generated by `postgres: postgres test [local] SELECT
'.
Program terminated with signal SIGABRT, Aborted.
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007faf78ccc859 in __GI_abort () at abort.c:79
#2 0x000055af27392a88 in ExceptionalCondition
(conditionName=conditionName@entry=0x55af274b0131 "stmt->constraints ==
NIL", errorType=errorType@entry=0x55af273f0498 "FailedAssertion",
fileName=fileName@entry=0x55af274ae8f8
"/home/postgres/postgresql-15.1/bld_debugging/../src/backend/parser/parse_utilcmd.c",
lineNumber=lineNumber@entry=307) at
/home/postgres/postgresql-15.1/bld_debugging/../src/backend/utils/error/assert.c:69
#3 0x000055af27049dbd in transformCreateStmt
(stmt=stmt@entry=0x55af287f9608,
queryString=queryString@entry=0x55af287f89b0 " CREATE TABLE table1 ( column0
INT CHECK ( 'x' = 'x' )) ; SELECT 1 ; ") at
/home/postgres/postgresql-15.1/bld_debugging/../src/backend/parser/parse_utilcmd.c:307
#4 0x000055af2726cff7 in ProcessUtilitySlow (pstate=0x55af287aa490,
pstmt=0x55af287fa1d0, queryString=0x55af287f89b0 " CREATE TABLE table1 (
column0 INT CHECK ( 'x' = 'x' )) ; SELECT 1 ; ",
context=PROCESS_UTILITY_QUERY, params=0x0, queryEnv=0x0, qc=0x0,
dest=<optimized out>) at
/home/postgres/postgresql-15.1/bld_debugging/../src/backend/tcop/utility.c:1147
#5 0x000055af2726c541 in standard_ProcessUtility (pstmt=0x55af287fa1d0,
queryString=0x55af287f89b0 " CREATE TABLE table1 ( column0 INT CHECK ( 'x' =
'x' )) ; SELECT 1 ; ", readOnlyTree=<optimized out>,
context=PROCESS_UTILITY_QUERY, params=0x0, queryEnv=0x0, dest=0x55af276a45a0
<donothingDR>, qc=0x0) at
/home/postgres/postgresql-15.1/bld_debugging/../src/backend/tcop/utility.c:1074
#6 0x000055af270e7cac in postquel_getnext (es=0x55af287fa268,
es=0x55af287fa268, fcache=0x55af287f8870, fcache=0x55af287f8870) at
/home/postgres/postgresql-15.1/bld_debugging/../src/backend/executor/functions.c:887
#7 fmgr_sql (fcinfo=0x55af287cc618) at
/home/postgres/postgresql-15.1/bld_debugging/../src/backend/executor/functions.c:1203
#8 0x000055af270d2683 in ExecInterpExpr (state=0x55af287cc530,
econtext=0x55af287cc0d8, isnull=<optimized out>) at
/home/postgres/postgresql-15.1/bld_debugging/../src/backend/executor/execExprInterp.c:1262
#9 0x000055af270e0c35 in ExecEvalExprSwitchContext (isNull=0x7ffce366c3f7,
econtext=0x55af287cc0d8, state=0x55af287cc530) at
/home/postgres/postgresql-15.1/bld_debugging/../src/include/executor/executor.h:341
#10 ExecProject (projInfo=0x55af287cc528) at
/home/postgres/postgresql-15.1/bld_debugging/../src/include/executor/executor.h:375
#11 ExecScan (node=<optimized out>, accessMtd=0x55af271125b0 <ValuesNext>,
recheckMtd=0x55af271125a0 <ValuesRecheck>) at
/home/postgres/postgresql-15.1/bld_debugging/../src/backend/executor/execScan.c:238
#12 0x000055af270d6c93 in ExecProcNode (node=0x55af287cbed0) at
/home/postgres/postgresql-15.1/bld_debugging/../src/include/executor/executor.h:259
#13 ExecutePlan (execute_once=<optimized out>, dest=0x55af287a5c50,
direction=<optimized out>, numberTuples=0, sendTuples=<optimized out>,
operation=CMD_SELECT, use_parallel_mode=<optimized out>,
planstate=0x55af287cbed0, estate=0x55af287cbc90) at
/home/postgres/postgresql-15.1/bld_debugging/../src/backend/executor/execMain.c:1636
#14 standard_ExecutorRun (queryDesc=0x55af287c57c0, direction=<optimized
out>, count=0, execute_once=<optimized out>) at
/home/postgres/postgresql-15.1/bld_debugging/../src/backend/executor/execMain.c:363
#15 0x000055af27269e5f in PortalRunSelect (portal=0x55af2874b560,
forward=<optimized out>, count=0, dest=<optimized out>) at
/home/postgres/postgresql-15.1/bld_debugging/../src/backend/tcop/pquery.c:924
#16 0x000055af2726b431 in PortalRun (portal=portal@entry=0x55af2874b560,
count=count@entry=9223372036854775807, isTopLevel=isTopLevel@entry=true,
run_once=run_once@entry=true, dest=dest@entry=0x55af287a5c50,
altdest=altdest@entry=0x55af287a5c50, qc=0x7ffce366c6a0) at
/home/postgres/postgresql-15.1/bld_debugging/../src/backend/tcop/pquery.c:768
#17 0x000055af27267202 in exec_simple_query (query_string=0x55af286de010
"SELECT function0 () FROM ( VALUES ( 1 ) , ( 1 ) ) AS alias0;") at
/home/postgres/postgresql-15.1/bld_debugging/../src/backend/tcop/postgres.c:1250
#18 0x000055af27268f8c in PostgresMain (dbname=<optimized out>,
username=<optimized out>) at
/home/postgres/postgresql-15.1/bld_debugging/../src/backend/tcop/postgres.c:4581
#19 0x000055af271d5e8a in BackendRun (port=<optimized out>, port=<optimized
out>) at
/home/postgres/postgresql-15.1/bld_debugging/../src/backend/postmaster/postmaster.c:4504
#20 BackendStartup (port=<optimized out>) at
/home/postgres/postgresql-15.1/bld_debugging/../src/backend/postmaster/postmaster.c:4232
#21 ServerLoop () at
/home/postgres/postgresql-15.1/bld_debugging/../src/backend/postmaster/postmaster.c:1806
#22 0x000055af271d6ffb in PostmasterMain (argc=<optimized out>,
argv=0x55af286d8310) at
/home/postgres/postgresql-15.1/bld_debugging/../src/backend/postmaster/postmaster.c:1478
#23 0x000055af26f01630 in main (argc=3, argv=0x55af286d8310) at
/home/postgres/postgresql-15.1/bld_debugging/../src/backend/main/main.c:202
I also find this assert failed in 14.6 using the same statement.
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: BUG #17702: An assert failed in parse_utilcmd.c
@ 2022-11-29 11:31 Daniel Gustafsson <daniel@yesql.se>
parent: PG Bug reporting form <noreply@postgresql.org>
0 siblings, 1 reply; 5+ messages in thread
From: Daniel Gustafsson @ 2022-11-29 11:31 UTC (permalink / raw)
To: xinwen@stu.scu.edu.cn; pgsql-bugs@lists.postgresql.org
> On 29 Nov 2022, at 03:45, PG Bug reporting form <noreply@postgresql.org> wrote:
> When executing the following query:
>
> CREATE FUNCTION function0 () RETURNS INT LANGUAGE SQL AS $$ CREATE TABLE
> table1 ( column0 INT CHECK ( 'x' = 'x' )) ; SELECT 1 ; $$ ;
> SELECT function0 () FROM ( VALUES ( 1 ) , ( 1 ) ) AS alias0;
>
> I get a failed assertion with the following stacktrace:
>
> Core was generated by `postgres: postgres test [local] SELECT
> '.
> Program terminated with signal SIGABRT, Aborted.
> #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
> #1 0x00007faf78ccc859 in __GI_abort () at abort.c:79
> #2 0x000055af27392a88 in ExceptionalCondition
> (conditionName=conditionName@entry=0x55af274b0131 "stmt->constraints ==
> NIL", errorType=errorType@entry=0x55af273f0498 "FailedAssertion",
> fileName=fileName@entry=0x55af274ae8f8
This is AFAICT due to the utility statement already having gone through parse
analysis and thus have the constraints list already set here. Forcing a read-
only protection via the functionality from 7c337b6b5 the assertion is avoided
and the function executes as expected:
inline patch 1: src/backend/executor/functions.c (+1/-1 lines) download inline-1.patch
diff --git a/src/backend/executor/functions.c b/src/backend/executor/functions.c
index e134a82ff7..b0941151b2 100644
--- a/src/backend/executor/functions.c
+++ b/src/backend/executor/functions.c
@@ -884,7 +884,7 @@ postquel_getnext(execution_state *es, SQLFunctionCachePtr fcache)
{
ProcessUtility(es->qd->plannedstmt,
fcache->src,
- false,
+ (nodeTag(es->qd->plannedstmt->utilityStmt) == T_CreateStmt ? true : false),
PROCESS_UTILITY_QUERY,
es->qd->params,
es->qd->queryEnv,
* Re: BUG #17702: An assert failed in parse_utilcmd.c
@ 2022-11-29 16:22 Tom Lane <tgl@sss.pgh.pa.us>
parent: Daniel Gustafsson <daniel@yesql.se>
0 siblings, 1 reply; 5+ messages in thread
From: Tom Lane @ 2022-11-29 16:22 UTC (permalink / raw)
To: Daniel Gustafsson <daniel@yesql.se>; +Cc: xinwen@stu.scu.edu.cn; pgsql-bugs@lists.postgresql.org
Daniel Gustafsson <daniel@yesql.se> writes:
>> On 29 Nov 2022, at 03:45, PG Bug reporting form <noreply@postgresql.org> wrote:
>> When executing the following query:
>>
>> CREATE FUNCTION function0 () RETURNS INT LANGUAGE SQL AS $$ CREATE TABLE
>> table1 ( column0 INT CHECK ( 'x' = 'x' )) ; SELECT 1 ; $$ ;
>> SELECT function0 () FROM ( VALUES ( 1 ) , ( 1 ) ) AS alias0;
>>
>> I get a failed assertion with the following stacktrace:
> This is AFAICT due to the utility statement already having gone through parse
> analysis and thus have the constraints list already set here. Forcing a read-
> only protection via the functionality from 7c337b6b5 the assertion is avoided
> and the function executes as expected:
Right.
> Maintaining a list of statements that scribble and force those to readonly
> could be a way forward? Forcing processing of all utility statements to be
> readonly seems like a blunt instrument here, not sure what the best course of
> action would be.
No, I think that's exactly what we should do. This is just a silly
oversight in 7c337b6b5 --- I should have thought about SQL functions
executing more than once in a query.
(Eventually we ought to nuke functions.c's private version of a plan
cache in favor of using plancache.c, but nobody's got to that yet.
It'd be more obvious then that we have to protect the cached copy.)
regards, tom lane
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: BUG #17702: An assert failed in parse_utilcmd.c
@ 2022-11-29 16:47 Daniel Gustafsson <daniel@yesql.se>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 5+ messages in thread
From: Daniel Gustafsson @ 2022-11-29 16:47 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: xinwen@stu.scu.edu.cn; pgsql-bugs@lists.postgresql.org
> On 29 Nov 2022, at 17:22, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Daniel Gustafsson <daniel@yesql.se> writes:
>>> On 29 Nov 2022, at 03:45, PG Bug reporting form <noreply@postgresql.org> wrote:
>>> When executing the following query:
>>>
>>> CREATE FUNCTION function0 () RETURNS INT LANGUAGE SQL AS $$ CREATE TABLE
>>> table1 ( column0 INT CHECK ( 'x' = 'x' )) ; SELECT 1 ; $$ ;
>>> SELECT function0 () FROM ( VALUES ( 1 ) , ( 1 ) ) AS alias0;
>>>
>>> I get a failed assertion with the following stacktrace:
>
>> This is AFAICT due to the utility statement already having gone through parse
>> analysis and thus have the constraints list already set here. Forcing a read-
>> only protection via the functionality from 7c337b6b5 the assertion is avoided
>> and the function executes as expected:
>
> Right.
Thanks for confirming.
>> Maintaining a list of statements that scribble and force those to readonly
>> could be a way forward? Forcing processing of all utility statements to be
>> readonly seems like a blunt instrument here, not sure what the best course of
>> action would be.
>
> No, I think that's exactly what we should do. This is just a silly
> oversight in 7c337b6b5 --- I should have thought about SQL functions
> executing more than once in a query.
Oh, ok. I'll go enforce readonly on all utility statements in HEAD and the
applicable backbranches tonight then.
--
Daniel Gustafsson https://vmware.com/
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: BUG #17702: An assert failed in parse_utilcmd.c
@ 2022-11-29 16:48 Daniel Gustafsson <daniel@yesql.se>
parent: Daniel Gustafsson <daniel@yesql.se>
0 siblings, 0 replies; 5+ messages in thread
From: Daniel Gustafsson @ 2022-11-29 16:48 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: xinwen@stu.scu.edu.cn; pgsql-bugs@lists.postgresql.org
> On 29 Nov 2022, at 17:47, Daniel Gustafsson <daniel@yesql.se> wrote:
> I'll go enforce readonly on all utility statements in HEAD and the
> applicable backbranches tonight then.
.. and just as I hit send I noticed that you had fixed it already =) Sorry for the noise.
--
Daniel Gustafsson https://vmware.com/
^ permalink raw reply [nested|flat] 5+ messages in thread
end of thread, other threads:[~2022-11-29 16:48 UTC | newest]
Thread overview: 5+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2022-11-29 02:45 BUG #17702: An assert failed in parse_utilcmd.c PG Bug reporting form <noreply@postgresql.org>
2022-11-29 11:31 ` Daniel Gustafsson <daniel@yesql.se>
2022-11-29 16:22 ` Tom Lane <tgl@sss.pgh.pa.us>
2022-11-29 16:47 ` Daniel Gustafsson <daniel@yesql.se>
2022-11-29 16:48 ` Daniel Gustafsson <daniel@yesql.se>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox