[Bug]: In concurrent mode, after introducing a deadlock for a period of time, the database crashes (caused by signal 6)

[getiancheng]

What happened?

reproduct_core_signal_6.tar.gz
Running on the Ubuntu operating system can reproduce this issue.

Version

BABEL_5_X_DEV (Default)

Extension

babelfishpg_tsql (Default)

Which flavor of Linux are you using when you see the bug?

Ubuntu (Default)

Relevant log output

errlog:
2026-03-04 09:27:07.257 UTC [45872] LOG:  server process (PID 71031) was terminated by signal 6: Aborted
2026-03-04 09:27:07.257 UTC [45872] DETAIL:  Failed process was running: drop procedure implicit_rollback_in_proc
2026-03-04 09:27:07.258 UTC [45872] LOG:  terminating any other active server processes
2026-03-04 09:27:07.525 UTC [45872] LOG:  all server processes terminated; reinitializing
2026-03-04 09:27:07.660 UTC [71380] LOG:  database system was interrupted; last known up at 2026-03-04 09:23:32 UTC
2026-03-04 09:27:07.775 UTC [71380] LOG:  database system was not properly shut down; automatic recovery in progress
2026-03-04 09:27:07.784 UTC [71380] LOG:  redo starts at 1/F256EC8
2026-03-04 09:27:09.946 UTC [71380] LOG:  invalid record length at 1/120DADE0: expected at least 24, got 0
2026-03-04 09:27:09.946 UTC [71380] LOG:  redo done at 1/120DAD48 system usage: CPU: user: 2.00 s, system: 0.15 s, elapsed: 2.16 s
2026-03-04 09:27:09.962 UTC [71381] LOG:  checkpoint starting: end-of-recovery immediate wait

Core file function call stack：
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `postgres: babelfish_user babelfish_db 127.0.0.1(42179) active                 '.
Program terminated with signal SIGABRT, Aborted.
#0  __pthread_kill_implementation (no_tid=0, signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:44
44      ./nptl/pthread_kill.c: No such file or directory.
(gdb) bt
#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@entry=6) at ./nptl/pthread_kill.c:89
#3  0x00007f899a43bc46 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#4  0x00007f899a4227fc in __GI_abort () at ./stdlib/abort.c:79
#5  0x00005590fbeec4e4 in errfinish (filename=0x5590fbf85b61 "xact.c", lineno=1769, funcname=0x5590fbf86dd0 <__func__.33646> "RecordTransactionAbort") at elog.c:603
#6  0x00005590fb8848f2 in RecordTransactionAbort (isSubXact=false) at xact.c:1769
#7  0x00005590fb885958 in AbortTransaction () at xact.c:2884
#8  0x00005590fb88626f in AbortCurrentTransactionInternal () at xact.c:3488
#9  0x00005590fb886197 in AbortCurrentTransaction () at xact.c:3406
#10 0x00007f898c31cb0c in dispatch_stmt_handle_error (estate=0x7ffff868df10, stmt=0x559101a26ad0, terminate_batch=0x7ffff868dce1, active_non_tsql_procs=0, active_sys_functions=0)
    at src/iterative_exec.c:1439
#11 0x00007f898c31d392 in exec_stmt_iterative (estate=0x7ffff868df10, exec_codes=0x559101a26f98, config=0x7ffff868dea0) at src/iterative_exec.c:1638
#12 0x00007f898c30ac5a in pltsql_exec_function (func=0x5590fdd60380, fcinfo=0x5590fd48e6b0, simple_eval_estate=0x559101af0228, atomic=false) at src/pl_exec.c:695
#13 0x00007f898c2ff81d in pltsql_inline_handler (fcinfo=0x7ffff868e4d0) at src/pl_handler.c:6696
#14 0x00007f8999e6aa9b in ExecuteSQLBatch (query=0x5590fd4d3f38 "drop procedure implicit_rollback_in_proc") at src/backend/tds/tdssqlbatch.c:94
#15 0x00007f8999e6ac8d in ProcessSQLBatchRequest (request=0x5590fd4d3f10) at src/backend/tds/tdssqlbatch.c:142
#16 0x00007f8999e55a95 in ProcessTDSRequest (request=0x5590fd4d3f10) at src/backend/tds/tdsprotocol.c:462
#17 0x00007f8999e5651a in TdsSocketBackend () at src/backend/tds/tdsprotocol.c:706
#18 0x00007f8999e607fb in pe_process_command () at src/backend/tds/tds_srv.c:560
#19 0x00005590fbd094ad in PostgresMain (dbname=0x5590fd4dae98 "babelfish_db", username=0x5590fd4dae38 "babelfish_user") at postgres.c:4795
#20 0x00007f8999e6068c in pe_mainfunc (port=0x5590fd489ae8) at src/backend/tds/tds_srv.c:494
#21 0x00005590fbd009c2 in BackendMain (startup_data=0x7ffff868eab0 "", startup_data_len=16) at backend_startup.c:105
#22 0x00005590fbc30835 in postmaster_child_launch (child_type=B_BACKEND, startup_data=0x7ffff868eab0 "", startup_data_len=16, client_sock=0x7ffff868eb10) at launch_backend.c:277
#23 0x00005590fbc36a10 in BackendStartup (client_sock=0x7ffff868eb10, protocol_config=0x7f8999e87dc0 <pe_config>) at postmaster.c:3772
#24 0x00005590fbc33e58 in ServerLoop () at postmaster.c:1852
#25 0x00005590fbc3333f in PostmasterMain (argc=3, argv=0x5590fd488b10) at postmaster.c:1413
#26 0x00005590fbaf6d55 in main (argc=3, argv=0x5590fd488b10) at main.c:199

Code of Conduct

• I agree to follow this project's Code of Conduct.

[tanscorpio7]

@getiancheng Thanks for reporting this. Did you run this same SQL concurrently

DROP PROCEDURE proc_test
GO

CREATE PROCEDURE proc_test AS  
BEGIN
END
GO

BEGIN TRANSACTION
	EXEC proc_test
COMMIT
GO

If yes, could you please try disabling pg_stat_statements and retrying the reproducing SQL ?

[getiancheng]

@getiancheng Thanks for reporting this. Did you run this same SQL concurrently

DROP PROCEDURE proc_test
GO

CREATE PROCEDURE proc_test AS  
BEGIN
END
GO

BEGIN TRANSACTION
	EXEC proc_test
COMMIT
GO

If yes, could you please try disabling pg_stat_statements and retrying the reproducing SQL ?

Yes, I just do it.
After disabling the pg_statements plugin, the issue with reproducing operations still persists.

[tanscorpio7]

@getiancheng dropping the pg_stat_statement does not disable the stats tracking.
Could you please try disabling track_functions

babelfish_db=# ALTER SYSTEM SET track_functions = 'none';
ALTER SYSTEM
babelfish_db=# SELECT pg_reload_conf();
 pg_reload_conf 
----------------
 t
(1 row)

We have seen a similar crash but that is in this error code path "trying to drop stats entry already dropped"

[getiancheng]

@tanscorpio7 Thanks for your timely response!
Indeed, after keeping pg_stat_statement and changing 'track_functions' to 'none', the process no longer crashes and everything appears to be back to normal!
I suspect that under high-concurrency scenarios, excessive accumulation of function statistics leads to illegal memory usage, which then triggers signal 6 and causes the database to restart. Does the Babelfish community have any next steps or a fix plan for this issue?

[getiancheng]

Also, please pay attention to the issue: #4285?
What is the progress on this?

[tanscorpio7]

@getiancheng Could you please check if #4285 is fixed in tip of dev branches. I suspect this commit babelfish-for-postgresql/postgresql_modified_for_babelfish@24caf69 might have fixed it.