From: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
---|---|
To: | a(dot)kozhemyakin(at)postgrespro(dot)ru, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #18947: TRAP: failed Assert("len_to_wrt >= 0") in pg_stat_statements |
Date: | 2025-06-07 16:49:53 |
Message-ID: | CAFiTN-tGux5MZ9Hk2wKv5sVhk7eDq2AHaT79LxnQbVamxoRn9Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Sat, Jun 7, 2025 at 9:10 PM PG Bug reporting form
<noreply(at)postgresql(dot)org> wrote:
>
> The following bug has been logged on the website:
>
> Bug reference: 18947
> Logged by: Alexander Kozhemyakin
> Email address: a(dot)kozhemyakin(at)postgrespro(dot)ru
> PostgreSQL version: 18beta1
> Operating system: Ubuntu 24.04
> Description:
>
> Hi, I encountered an assertion failure when running the following query on
> the master branch (commit 112e40b8) when building with --enable-cassert
> reproduce
> initdb -D data
> echo "
> shared_preload_libraries = 'pg_stat_statements'
> " > data/postgresql.auto.conf
> pg_ctl -D data -l logfile start
> psql <<EOF
> (values(1)) limit 1;
> EOF
> bt
> (gdb)
> #0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=<optimized
> out>) at ./nptl/pthread_kill.c:44
> #1 __pthread_kill_internal (signo=6, threadid=<optimized out>) at
> ./nptl/pthread_kill.c:78
> #2 __GI___pthread_kill (threadid=<optimized out>, signo=signo(at)entry=6) at
> ./nptl/pthread_kill.c:89
> #3 0x00007b9ecba4527e in __GI_raise (sig=sig(at)entry=6) at
> ../sysdeps/posix/raise.c:26
> #4 0x00007b9ecba288ff in __GI_abort () at ./stdlib/abort.c:79
> #5 0x00005ee635e0da6f in ExceptionalCondition
> (conditionName=conditionName(at)entry=0x7b9ecc55f97d "len_to_wrt >= 0",
> fileName=fileName(at)entry=0x7b9ecc55f000
> "/home/postgres/test/postgres/contrib/pg_stat_statements/pg_stat_statements.c",
> lineNumber=lineNumber(at)entry=2929)
> at /home/postgres/test/postgres/src/backend/utils/error/assert.c:66
> #6 0x00007b9ecc55c5a6 in generate_normalized_query
> (query_len_p=0x7fff53b9a348, query_loc=1, query=0x5ee6575d0df1 "values(1))
> limit 1;", jstate=0x5ee657606e88) at
> /home/postgres/test/postgres/contrib/pg_stat_statements/pg_stat_statements.c:2929
> #7 pgss_store (query=0x5ee6575d0df1 "values(1)) limit 1;",
> queryId=<optimized out>, query_location=<optimized out>,
> query_len=<optimized out>, kind=kind(at)entry=PGSS_INVALID,
> total_time=total_time(at)entry=0, rows=rows(at)entry=0, bufusage=0x0,
> walusage=0x0, jitusage=0x0, jstate=0x5ee657606e88,
> parallel_workers_to_launch=0, parallel_workers_launched=0) at
> /home/postgres/test/postgres/contrib/pg_stat_statements/pg_stat_statements.c:1350
> #8 0x00007b9ecc55c6ca in pgss_post_parse_analyze (pstate=0x5ee6575d1a98,
> query=0x5ee6575d1ba8, jstate=0x5ee657606e88) at
> /home/postgres/test/postgres/contrib/pg_stat_statements/pg_stat_statements.c:868
> #9 0x00005ee6359f46cb in parse_analyze_fixedparams
> (parseTree=parseTree(at)entry=0x5ee6575d1a18,
> sourceText=sourceText(at)entry=0x5ee6575d0df0 "(values(1)) limit 1;",
> paramTypes=paramTypes(at)entry=0x0, numParams=numParams(at)entry=0,
> queryEnv=queryEnv(at)entry=0x0)
> at /home/postgres/test/postgres/src/backend/parser/analyze.c:128
> #10 0x00005ee635cb71a0 in pg_analyze_and_rewrite_fixedparams (queryEnv=0x0,
> numParams=0, paramTypes=0x0, query_string=<optimized out>,
> parsetree=<optimized out>) at
> /home/postgres/test/postgres/src/backend/tcop/postgres.c:682
> #11 exec_simple_query (query_string=0x5ee6575d0df0 "(values(1)) limit 1;")
> at /home/postgres/test/postgres/src/backend/tcop/postgres.c:1189
> #12 0x00005ee635cb8eb0 in PostgresMain (dbname=<optimized out>,
> username=<optimized out>) at
> /home/postgres/test/postgres/src/backend/tcop/postgres.c:4766
> #13 0x00005ee635cb3293 in BackendMain (startup_data=<optimized out>,
> startup_data_len=<optimized out>) at
> /home/postgres/test/postgres/src/backend/tcop/backend_startup.c:124
> #14 0x00005ee635c021e2 in postmaster_child_launch (child_type=<optimized
> out>, child_slot=1, startup_data=startup_data(at)entry=0x7fff53b9a9d0,
> startup_data_len=startup_data_len(at)entry=24,
> client_sock=client_sock(at)entry=0x7fff53b9a9f0) at
> /home/postgres/test/postgres/src/backend/postmaster/launch_backend.c:290
> #15 0x00005ee635c06014 in BackendStartup (client_sock=0x7fff53b9a9f0) at
> /home/postgres/test/postgres/src/backend/postmaster/postmaster.c:3580
> #16 ServerLoop () at
> /home/postgres/test/postgres/src/backend/postmaster/postmaster.c:1702
> #17 0x00005ee635c07b0e in PostmasterMain (argc=argc(at)entry=3,
> argv=argv(at)entry=0x5ee65758a0b0) at
> /home/postgres/test/postgres/src/backend/postmaster/postmaster.c:1400
> #18 0x00005ee6358d3f4e in main (argc=3, argv=0x5ee65758a0b0) at
> /home/postgres/test/postgres/src/backend/main/main.c:227
I didn't get time to debug, I might look into it tomorrow if someone
doesn't do it before that, but I am able to reproduce the issue and
seems like problem is with respect to computing the quer_loc in below
loop, and due to that 'quer_loc' is becoming bigger than query_len and
hitting the assert.
for (i = 0; i < jstate->clocations_count; i++)
{
...
quer_loc = off + tok_len;
}
len_to_wrt = query_len - quer_loc;
--
Regards,
Dilip Kumar
Google
From | Date | Subject | |
---|---|---|---|
Next Message | Laurenz Albe | 2025-06-08 00:27:31 | Re: BUG #18950: pgsql function that worked in Postgresql 16 does not return in Postgresql 17 |
Previous Message | Tom Lane | 2025-06-07 16:09:48 | Re: BUG #18948: Equivalent MAX() result in view and inline query yields inconsistent row count |