Обсуждение: BUG #19067: On master at commit 66cdef4425f3, "psql -c 'select 1' dbname" causes the backend to seg fault

The following bug has been logged on the website:

Bug reference:      19067
Logged by:          Todd Cook
Email address:      cookt@blackduck.com
PostgreSQL version: Unsupported/Unknown
Operating system:   CentOS Stream 9
Description:

Running this command:

    psql -h localhost -p $PG19_PORT -c "select 1;" testdb

causes the backend to seg fault using psql from both 66cdef4425f3 and 18.0.

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x000000000071ea84 in expr_setup_walker (node=0x1, info=0x7ffc91951b90)
at executor/execExpr.c:2987
2987            if (IsA(node, Var))
(gdb)
(gdb) bt
#0  0x000000000071ea84 in expr_setup_walker (node=0x1, info=0x7ffc91951b90)
at executor/execExpr.c:2987
#1  0x0000000000726a2c in ExecCreateExprSetupSteps (node=0x1,
state=0x2d5c600) at executor/execExpr.c:2886
#2  ExecInitQual (qual=0x1, parent=<optimized out>) at
executor/execExpr.c:250
#3  0x0000000000766cfa in ExecInitResult (node=0x2d5a6e8, estate=0x2d5baa8,
eflags=32) at executor/nodeResult.c:227
#4  0x0000000000738ccf in ExecInitNode (node=0x2d5a6e8, estate=0x2d5baa8,
eflags=<optimized out>) at executor/execProcnode.c:167
#5  0x000000000073036c in InitPlan (eflags=32, queryDesc=<optimized out>) at
executor/execMain.c:987
#6  standard_ExecutorStart (queryDesc=<optimized out>, eflags=32) at
executor/execMain.c:261
#7  0x00007fabc964120d in pgss_ExecutorStart (queryDesc=0x2cc8358,
eflags=<optimized out>) at
/home/tac/git_other/postgres/contrib/pg_stat_statements/pg_stat_statements.c:1004
#8  0x0000000000931e08 in ExecutorStart (eflags=0, queryDesc=0x2cc8358) at
executor/execMain.c:135
#9  PortalStart (portal=portal@entry=0x2dcff48, params=params@entry=0x0,
eflags=eflags@entry=0, snapshot=snapshot@entry=0x0) at tcop/pquery.c:518
#10 0x0000000000932159 in exec_simple_query (query_string=0x2d03df8 "select
1;") at tcop/postgres.c:1239
#11 0x00000000009346cb in PostgresMain (dbname=<optimized out>,
username=<optimized out>) at tcop/postgres.c:4774
#12 0x0000000000929e55 in BackendMain (startup_data=<optimized out>,
startup_data_len=<optimized out>) at tcop/backend_startup.c:124
#13 0x0000000000882d8d in postmaster_child_launch (child_type=<optimized
out>, child_slot=1, startup_data=0x7ffc91952450, startup_data_len=24,
client_sock=0x7ffc91952470) at postmaster/launch_backend.c:268
#14 0x000000000088dd2d in BackendStartup (client_sock=0x7ffc91952470) at
postmaster/postmaster.c:3590
#15 ServerLoop () at postmaster/postmaster.c:1705
#16 0x000000000088474b in PostmasterMain (argc=3, argv=0x2cbf1e0) at
postmaster/postmaster.c:1403
#17 0x000000000052d4a0 in main (argc=3, argv=0x2cbf1e0) at main/main.c:231

On Sat, 27 Sept 2025 at 21:03, PG Bug reporting form
<noreply@postgresql.org> wrote:
>     psql -h localhost -p $PG19_PORT -c "select 1;" testdb
>
> causes the backend to seg fault using psql from both 66cdef4425f3 and 18.0.

I think it's more likely you need to do "make clean" before building.

David

On 9/27/25, 5:07 AM, "David Rowley" <dgrowleyml@gmail.com <mailto:dgrowleyml@gmail.com>> wrote:
>
> I think it's more likely you need to do "make clean" before building.

Thanks.

Generally, when is that needed?  I pulled and built master last Monday without any problems,
didn't touch the tree, then pulled and built again on Friday and started getting the seg faults.
I had expected an incremental build to work in that scenario.

-- todd

Todd Cook <cookt@blackduck.com> writes:
> On 9/27/25, 5:07 AM, "David Rowley" <dgrowleyml@gmail.com <mailto:dgrowleyml@gmail.com>> wrote:
>> I think it's more likely you need to do "make clean" before building.

> Generally, when is that needed?  I pulled and built master last Monday without any problems,
> didn't touch the tree, then pulled and built again on Friday and started getting the seg faults.
> I had expected an incremental build to work in that scenario.

If you use --enable-depend that should generally work, but without
it you'd better "make clean" any time *.h files change.

            regards, tom lane