Second call of pg_reload_conf() after calling any duckdb function crashes the server

[ggnmstr]

What happens?

Second call of pg_reload_conf() after calling any duckdb function crashes the server.

To Reproduce

1. Start a fresh PostgreSQL server with pg_duckdb in shared_preload_libraries
2. Run this script:

create extension pg_duckdb ;
create table test(a int);
insert into test (a) values (5);

copy test to '/tmp/test.parquet';

select pg_reload_conf();
select pg_reload_conf();

3. After second call of pg_reload_conf() server will crash:

server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
The connection to the server was lost. Attempting reset: Failed.

Logs:

TRAP: failed Assert("IsTransactionState()"), File: "catcache.c", Line: 1378, PID: 360610
postgres: jorq postgres [local] idle(ExceptionalCondition+0x57) [0x9576f7]
postgres: jorq postgres [local] idle() [0x93fc15]
postgres: jorq postgres [local] idle(GetSysCacheOid+0x2e) [0x9534ae]
postgres: jorq postgres [local] idle(get_namespace_oid+0x27) [0x579fb7]
/usr/local/lib/postgresql/pg_duckdb.so(+0x28d02) [0x7f889b380d02]
/usr/local/lib/postgresql/pg_duckdb.so(+0x2925e) [0x7f889b38125e]
/usr/local/lib/postgresql/pg_duckdb.so(+0x2c9c4) [0x7f889b3849c4]
postgres: jorq postgres [local] idle(set_config_with_handle+0x1190) [0x9713d0]
postgres: jorq postgres [local] idle(ProcessConfigFileInternal+0x440) [0x972ca0]
postgres: jorq postgres [local] idle(ProcessConfigFile+0x62) [0x9766b2]
postgres: jorq postgres [local] idle(PostgresMain+0xfb6) [0x8203b6]
postgres: jorq postgres [local] idle(BackendMain+0x4d) [0x81b5ed]
postgres: jorq postgres [local] idle(postmaster_child_launch+0xb1) [0x780001]
postgres: jorq postgres [local] idle() [0x783d98]
postgres: jorq postgres [local] idle(PostmasterMain+0xd74) [0x7858b4]
postgres: jorq postgres [local] idle(main+0x1e8) [0x48e798]
/lib64/libc.so.6(+0x3575) [0x7f889b411575]
/lib64/libc.so.6(__libc_start_main+0x88) [0x7f889b411628]
postgres: jorq postgres [local] idle(_start+0x25) [0x48ea75]
2025-09-25 18:23:11.962 MSK [360591] LOG:  server process (PID 360610) was terminated by signal 6: Aborted
2025-09-25 18:23:11.962 MSK [360591] DETAIL:  Failed process was running: select pg_reload_conf();
2025-09-25 18:23:11.962 MSK [360591] LOG:  terminating any other active server processes
2025-09-25 18:23:11.962 MSK [360784] FATAL:  the database system is in recovery mode
2025-09-25 18:23:11.963 MSK [360591] LOG:  all server processes terminated; reinitializing
2025-09-25 18:23:11.977 MSK [360785] LOG:  database system was interrupted; last known up at 2025-09-25 18:22:15 MSK
2025-09-25 18:23:12.000 MSK [360785] LOG:  database system was not properly shut down; automatic recovery in progress
2025-09-25 18:23:12.001 MSK [360785] LOG:  redo starts at 0/154D1E8
2025-09-25 18:23:12.004 MSK [360785] LOG:  invalid record length at 0/167BEB0: expected at least 24, got 0
2025-09-25 18:23:12.004 MSK [360785] LOG:  redo done at 0/167BE78 system usage: CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s
2025-09-25 18:23:12.006 MSK [360786] LOG:  checkpoint starting: end-of-recovery immediate wait
2025-09-25 18:23:12.103 MSK [360786] LOG:  checkpoint complete: wrote 230 buffers (1.4%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.008 s, sync=0.085 s, total=0.098 s; sync files=115, longest=0.002 s, average=0.001 s; distance=1211 kB, estimate=1211 kB; lsn=0/167BEB0, redo lsn=0/167BEB0
2025-09-25 18:23:12.105 MSK [360591] LOG:  database system is ready to accept connections

OS:

Linux

pg_duckdb Version (if built from source use commit hash):

a8b1e10

Postgres Version (if built from source use commit hash):

53a2246ddf9b1e641654dd0654ff8f24e952920a

Hardware:

No response

Full Name:

Jora Babayan

Affiliation:

Postgres Professional

What is the latest build you tested with? If possible, we recommend testing with the latest nightly build.

I have not tested with any build

Did you include all relevant data sets for reproducing the issue?

No - Other reason (please specify in the issue body)

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

[JelteF]

Okay, that's obviously not great. I think it could be related to #867

[JelteF]

Could you check if #936 solves it for you?

[ggnmstr]

Unfortunately, #936 did not help

[ggnmstr]

Found out some details that may help with understanding the problem.

So, if we run the same scenario, but provide the COPY statement in 2 lines, server will not crash.
This is the example:

postgres=# copy test to '/tmp/test.parquet
postgres'# ';
COPY 1

After running this COPY statement, server will NOT crash due to multiple calls of pg_reload_conf()

This may be somehow related to DuckdbUtilityHook_Cpp, becase in this case code below is NOT executed:

static void
DuckdbUtilityHook_Cpp(PlannedStmt *pstmt, const char *query_string, bool read_only_tree, ProcessUtilityContext context,
                      ParamListInfo params, struct QueryEnvironment *query_env, DestReceiver *dest,
                      QueryCompletion *qc) {
	Node *parsetree = pstmt->utilityStmt;
	if (IsA(parsetree, CopyStmt)) {
		auto copy_query = PostgresFunctionGuard(MakeDuckdbCopyQuery, pstmt, query_string, query_env);
		if (copy_query) { 
            // This branch is not executed if we provide copy statement like above!
			auto res = pgduckdb::DuckDBQueryOrThrow(copy_query);
			auto chunk = res->Fetch();
			auto processed = chunk->GetValue(0, 0).GetValue<uint64_t>();
			if (qc) {
				SetQueryCompletion(qc, CMDTAG_COPY, processed);
			}
			return;
		}
	}

[YuweiXiao]

I can reproduce the issue. The backtrace:

postgres=# copy test to '/tmp/test.parquet
postgres'# ';
COPY 1

Appending a new line to the filename will trick the server to use Postgres to do the copy instead, i.e., csv format. So no duckdb connection is initialized.