Server crashes on executing SELECT query #976
Description
What happens?
PostgreSQL crashes on executing the following actions
PostgreSQL configure:
CPPFLAGS="-Og -fsanitize=address -fsanitize=undefined \
-fno-sanitize-recover=all -fno-sanitize=nonnull-attribute -fstack-protector" \
LDFLAGS='-fsanitize=address -fsanitize=undefined -static-libasan' \
./configure --enable-tap-tests --enable-debug --enable-cassert --with-openssl --with-icu --with-lz4 --with-libxml --quiet --prefix=$PGPREFIX
export ASAN_OPTIONS=detect_stack_use_after_return=0:detect_leaks=0:abort_on_error=1:disable_coredump=0:strict_string_checks=1:check_initialization_order=1:strict_init_order=1:detect_odr_violation=0
To Reproduce
PostgreSQL conf:
shared_preload_libraries='pg_duckdb'
duckdb.force_execution = true
duckdb.postgres_role = 'duckdb_group'
log_temp_files = -1
Steps:
echo "
\getenv abs_srcdir PG_ABS_SRCDIR
CREATE TABLE tenk1 (
unique1 int4,
unique2 int4,
two int4,
four int4,
ten int4,
twenty int4,
hundred int4,
thousand int4,
twothousand int4,
fivethous int4,
tenthous int4,
odd int4,
even int4,
stringu1 name,
stringu2 name,
string4 name
);
\set filename :abs_srcdir '/data/tenk.data'
COPY tenk1 FROM :'filename';
CREATE TABLE tenk2 AS SELECT * FROM tenk1 ORDER BY unique2;
VACUUM ANALYZE tenk2;
SELECT four, ten,
sum(ten) over (partition by four order by ten),
last_value(ten) over (partition by four order by ten)
FROM (select distinct ten, four from tenk1) ss;
" > postgres/src/test/regress/sql/test.sql
touch postgres/src/test/regress/expected/test.out
EXTRA_REGRESS_OPTS='--load-extension=pg_duckdb' make installcheck-tests TESTS='test'
# +++ regress install-check in src/test/regress +++
# using postmaster on Unix socket, default port
NOTICE: extension "pg_duckdb" already exists, skipping
not ok 1 - test 1241 ms
# (test process exited with exit code 2)
1..1
# 1 of 1 tests failed.
# The differences that caused some tests to fail can be viewed in the file "/home/test/postgres/src/test/regress/regression.diffs".
# A copy of the test summary that you see above is saved in the file "/home/test/postgres/src/test/regress/regression.out".
backtrace:
#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
#1 0x00007f603adc8f4f in __pthread_kill_internal (signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:78
#2 0x00007f603ad79fb2 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#3 0x00007f603ad64472 in __GI_abort () at ./stdlib/abort.c:79
#4 0x00005581e200e51f in __sanitizer::Abort() ()
#5 0x00005581e201abb1 in __sanitizer::Die() ()
#6 0x00005581e1ff9f6e in __asan::ScopedInErrorReport::~ScopedInErrorReport() ()
#7 0x00005581e1ff94d6 in __asan::ReportGenericError(unsigned long, unsigned long, unsigned long, unsigned long, bool, unsigned long, unsigned int, bool) ()
#8 0x00005581e1f801ba in memcpy ()
#9 0x00007f60363d33e5 in pgduckdb::PostgresTableReader::GetNextMinimalWorkerTuple (this=this@entry=0x6070002129e0, minimal_tuple_buffer=std::vector of length 34, capacity 34 = {...}) at src/scan/postgres_table_reader.cpp:319
#10 0x00007f60363add5c in pgduckdb::PostgresScanTableFunction::PostgresScanFunction (data=..., output=...) at src/scan/postgres_scan.cpp:605
#11 0x00007f6034186fac in duckdb::PhysicalTableScan::GetData(duckdb::ExecutionContext&, duckdb::DataChunk&, duckdb::OperatorSourceInput&) const () from /home/test/pgsql/lib/libduckdb.so
#12 0x00007f6034343c3d in duckdb::PipelineExecutor::FetchFromSource(duckdb::DataChunk&) () from /home/test/pgsql/lib/libduckdb.so
#13 0x00007f603434c1e7 in duckdb::PipelineExecutor::Execute(unsigned long) () from /home/test/pgsql/lib/libduckdb.so
#14 0x00007f603434c5a2 in duckdb::PipelineTask::ExecuteTask(duckdb::TaskExecutionMode) () from /home/test/pgsql/lib/libduckdb.so
#15 0x00007f6034344f51 in duckdb::ExecutorTask::Execute(duckdb::TaskExecutionMode) () from /home/test/pgsql/lib/libduckdb.so
#16 0x00007f603434d362 in duckdb::Executor::ExecuteTask(bool) () from /home/test/pgsql/lib/libduckdb.so
#17 0x00007f60342fe4a0 in duckdb::ClientContext::ExecuteTaskInternal(duckdb::ClientContextLock&, duckdb::BaseQueryResult&, bool) () from /home/test/pgsql/lib/libduckdb.so
#18 0x00007f60342fe661 in duckdb::PendingQueryResult::ExecuteTask() () from /home/test/pgsql/lib/libduckdb.so
#19 0x00007f60362d7465 in ExecuteQuery (state=state@entry=0x62500004b428) at src/pgduckdb_node.cpp:209
#20 0x00007f60362d9512 in Duckdb_ExecCustomScan_Cpp (node=0x62500004b428) at src/pgduckdb_node.cpp:268
#21 0x00007f60362da5ce in pgduckdb::__CPPFunctionGuard__<TupleTableSlot* (*)(CustomScanState*), Duckdb_ExecCustomScan_Cpp, CustomScanState*> (func_name=func_name@entry=0x7f603643c980 "Duckdb_ExecCustomScan_Cpp",
file_name=file_name@entry=0x7f603643b20f "src/pgduckdb_node.cpp", line=line@entry=329) at src/pgduckdb_node.cpp:329
#22 0x00007f60362dae99 in Duckdb_ExecCustomScan (node=<optimized out>) at src/pgduckdb_node.cpp:329
#23 0x00005581e281b417 in ExecCustomScan (pstate=<optimized out>) at nodeCustom.c:121
#24 0x00005581e27c34e4 in ExecProcNodeFirst (node=0x62500004b428) at execProcnode.c:464
#25 0x00005581e279f04a in ExecProcNode (node=node@entry=0x62500004b428) at ../../../src/include/executor/executor.h:278
#26 0x00005581e27a0567 in ExecutePlan (queryDesc=queryDesc@entry=0x619000007e80, operation=operation@entry=CMD_SELECT, sendTuples=sendTuples@entry=true, numberTuples=numberTuples@entry=0, direction=direction@entry=ForwardScanDirection,
dest=dest@entry=0x62d000320838) at execMain.c:1689
#27 0x00005581e27a2e53 in standard_ExecutorRun (queryDesc=0x619000007e80, direction=ForwardScanDirection, count=0, execute_once=execute_once@entry=false) at execMain.c:360
#28 0x00005581e27a2ed7 in ExecutorRun (queryDesc=queryDesc@entry=0x619000007e80, direction=direction@entry=ForwardScanDirection, count=count@entry=0, execute_once=execute_once@entry=false) at execMain.c:306
#29 0x00005581e2f1540e in PortalRunSelect (portal=portal@entry=0x625000034a00, forward=forward@entry=true, count=0, count@entry=9223372036854775807, dest=dest@entry=0x62d000320838) at pquery.c:922
#30 0x00005581e2f1afbc in PortalRun (portal=portal@entry=0x625000034a00, count=count@entry=9223372036854775807, isTopLevel=isTopLevel@entry=true, run_once=run_once@entry=true, dest=dest@entry=0x62d000320838, altdest=altdest@entry=0x62d000320838,
qc=<optimized out>) at pquery.c:766
#31 0x00005581e2f0f4a8 in exec_simple_query (
query_string=query_string@entry=0x625000007a00 "SELECT four, ten,\n\tsum(ten) over (partition by four order by ten),\n\tlast_value(ten) over (partition by four order by ten)\nFROM (select distinct ten, four from tenk1) ss;") at postgres.c:1278
#32 0x00005581e2f13f2d in PostgresMain (dbname=dbname@entry=0x6290000204b0 "regression", username=username@entry=0x629000020498 "test") at postgres.c:4767
#33 0x00005581e2f0308a in BackendMain (startup_data=startup_data@entry=0x7ffe8010fa60 "", startup_data_len=startup_data_len@entry=4) at backend_startup.c:105
#34 0x00005581e2cb4100 in postmaster_child_launch (child_type=child_type@entry=B_BACKEND, startup_data=startup_data@entry=0x7ffe8010fa60 "", startup_data_len=startup_data_len@entry=4, client_sock=client_sock@entry=0x7ffe80110190)
at launch_backend.c:277
#35 0x00005581e2cbdb88 in BackendStartup (client_sock=client_sock@entry=0x7ffe80110190) at postmaster.c:3596
#36 0x00005581e2cbe58a in ServerLoop () at postmaster.c:1678
#37 0x00005581e2cc0bad in PostmasterMain (argc=argc@entry=3, argv=argv@entry=0x6030000002e0) at postmaster.c:1376
#38 0x00005581e29200a6 in main (argc=3, argv=0x6030000002e0) at main.c:199
OS:
debian-12
pg_duckdb Version (if built from source use commit hash):
Postgres Version (if built from source use commit hash):
1cd020324ef5f9e9651e834643fd5166b21c749a
Hardware:
No response
Full Name:
Egor Chindyaskin
Affiliation:
Postgres Professional
What is the latest build you tested with? If possible, we recommend testing with the latest nightly build.
I have tested with a source build
Did you include all relevant data sets for reproducing the issue?
Yes
Did you include all code required to reproduce the issue?
- Yes, I have
Did you include all relevant configuration (e.g., CPU architecture, Linux distribution) to reproduce the issue?
- Yes, I have