Running the fdw test from the terminal crashes into the core-dump

From: Alena Rybakina <a(dot)rybakina(at)postgrespro(dot)ru>
To: Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Running the fdw test from the terminal crashes into the core-dump
Date: 2024-02-18 18:33:07
Message-ID: 4d65a385-7efa-4436-a825-0869f89d9d92@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi, hackers!

After starting the server (initdb + pg_ctl start) I ran a regress test
create_misc.sql ('\i src/test/regress/sql/create_misc.sql') and, after
that,
I ran the fdw test ('\i contrib/postgres_fdw/sql/postgres_fdw.sql') in
the psql, and it failed in the core-dump due to the worked assert.

To be honest, such a failure occurred only if the fdw extension was not
installed earlier.

script to reproduce the error:

./configure CFLAGS='-g -ggdb -O0' --enable-debug --enable-cassert
--prefix=`pwd`/tmp_install && make -j8 -s install

export CDIR=$(pwd)
export PGDATA=$CDIR/postgres_data
rm -r $PGDATA
mkdir $PGDATA
${CDIR}/tmp_install/bin/initdb -D $PGDATA >> log.txt
${CDIR}/tmp_install/bin/pg_ctl -D $PGDATA -l logfile start

${CDIR}/tmp_install/bin/psql -d postgres -f
src/test/regress/sql/create_misc.sql &&
${CDIR}/tmp_install/bin/psql -d postgres -f
contrib/postgres_fdw/sql/postgres_fdw.sql

The query, where the problem is:

-- MERGE ought to fail cleanly
merge into itrtest using (select 1, 'foo') as source on (true)
  when matched then do nothing;

Coredump:

#5  0x0000555d1451f483 in ExceptionalCondition
(conditionName=0x555d146bba13 "requiredPerms != 0",
fileName=0x555d146bb7b0 "execMain.c",
    lineNumber=654) at assert.c:66
#6  0x0000555d14064ebe in ExecCheckOneRelPerms (perminfo=0x555d1565ef90)
at execMain.c:654
#7  0x0000555d14064d94 in ExecCheckPermissions
(rangeTable=0x555d1565eef0, rteperminfos=0x555d1565efe0,
ereport_on_violation=true) at execMain.c:623
#8  0x0000555d140652ca in InitPlan (queryDesc=0x555d156cde50, eflags=0)
at execMain.c:850
#9  0x0000555d140644a8 in standard_ExecutorStart
(queryDesc=0x555d156cde50, eflags=0) at execMain.c:266
#10 0x0000555d140641ec in ExecutorStart (queryDesc=0x555d156cde50,
eflags=0) at execMain.c:145
#11 0x0000555d1432c025 in ProcessQuery (plan=0x555d1565f3e0,
    sourceText=0x555d1551b020 "merge into itrtest using (select 1,
'foo') as source on (true)\n  when matched then do nothing;", params=0x0,
    queryEnv=0x0, dest=0x555d1565f540, qc=0x7fffc9454080) at pquery.c:155
#12 0x0000555d1432dbd8 in PortalRunMulti (portal=0x555d15597ef0,
isTopLevel=true, setHoldSnapshot=false, dest=0x555d1565f540,
altdest=0x555d1565f540,
    qc=0x7fffc9454080) at pquery.c:1277
#13 0x0000555d1432d0cf in PortalRun (portal=0x555d15597ef0,
count=9223372036854775807, isTopLevel=true, run_once=true,
dest=0x555d1565f540,
    altdest=0x555d1565f540, qc=0x7fffc9454080) at pquery.c:791
#14 0x0000555d14325ec8 in exec_simple_query (
--Type <RET> for more, q to quit, c to continue without paging--
    query_string=0x555d1551b020 "merge into itrtest using (select 1,
'foo') as source on (true)\n  when matched then do nothing;") at
postgres.c:1273
#15 0x0000555d1432ae4c in PostgresMain (dbname=0x555d15555ab0 "aaa",
username=0x555d15555a98 "alena") at postgres.c:4645
#16 0x0000555d14244a5d in BackendRun (port=0x555d1554b3b0) at
postmaster.c:4440
#17 0x0000555d14244072 in BackendStartup (port=0x555d1554b3b0) at
postmaster.c:4116
#18 0x0000555d142405c5 in ServerLoop () at postmaster.c:1768
#19 0x0000555d1423fec2 in PostmasterMain (argc=3, argv=0x555d1547fcf0)
at postmaster.c:1467
#20 0x0000555d140f3122 in main (argc=3, argv=0x555d1547fcf0) at main.c:198

This error is consistently reproduced.

To be honest, I wasn't able to fully figure out the reason for this, but
it seems that this operation on partitions should not be available at all?

alena(at)postgres=# SELECT relname, relkind FROM pg_class where
relname='itrtest';
 relname | relkind
---------+---------
 itrtest | p
(1 row)

--
Regards,
Alena Rybakina
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Erik Wienhold 2024-02-18 18:49:58 Re: Patch: Add parse_type Function
Previous Message Alexander Lakhin 2024-02-18 18:00:00 Re: Removing unneeded self joins