Hello hackers,
23.10.2026 08:05, Manu wrote:
One case is still stuck. A backend can block while it sends an error.
It holds interrupts then, so SIGTERM does nothing. v2 still logs
"terminating process". That can confuse users.
Reproduced with SELECT repeat('x', 30000000)::int from a client that
does not read: the backend sits in EmitErrorReport() -> ... ->
secure_write() with InterruptHoldoffCount = 1 and wait event
ClientWrite. After pg_terminate_backend() it was still there 10 s
later, 3/3 on master and on v2, and v2 logged "terminating process".
I'm sorry for being late to this train and maybe a bit off-topic, but I'd
like to share one more way to have a backend blocked on connection due to
a barrier not absorbed:
echo "
synchronous_standby_names = 'nosuch'
synchronous_commit = local
authentication_timeout = 10s
log_connections = on
" > $PGDATA/postgresql.auto.conf
pg_ctl -l server.log -w start
psql -c "SHOW procsignal_barrier_timeout"
psql -c "CREATE DATABASE victim"
psql -c "SET synchronous_commit = remote_apply" -c "CREATE TABLE t ()" &
sleep 1
psql -c "DROP DATABASE victim WITH (FORCE)" &
sleep 1
psql -c "VACUUM FULL pg_subscription" &
sleep 2
psql -c "VACUUM FULL pg_authid"
echo "Test connection..."
date
timeout 60 psql -c "SELECT 1" || echo "Connection timeout"
date
pg_ctl -m fast stop
wait
The script produces:
procsignal_barrier_timeout
----------------------------
30s
(1 row)
CREATE DATABASE
SET
VACUUM
Test connection...
Fri Oct 23 12:21:18 PM EEST 2026
Connection timeout
Fri Oct 23 12:22:18 PM EEST 2026
2026-10-23 12:21:18.412 EEST [3519423] LOG: connection received: host=[local]
2026-10-23 12:21:18.413 EEST [3519423] LOG: connection authenticated:
user="law" method=trust (.../pg_hba.conf:117)
2026-10-23 12:21:18.413 EEST [3519423] LOG: connection authorized: user=law
database=postgres application_name=psql
2026-10-23 12:21:19.417 EEST [3519423] LOG: process 3519423 still waiting for AccessShareLock on relation 6100 of
database 0 after 1000.027 ms
2026-10-23 12:21:19.417 EEST [3519423] DETAIL: Process holding the lock:
3519408. Wait queue: 3519413, 3519423.
2026-10-23 12:21:19.417 EEST [3519423] CONTEXT: waiting for AccessShareLock on
relation 6100 of database 0
2026-10-23 12:21:20.418 EEST [3519408] LOG: still waiting for backend with PID
3519403 to accept ProcSignalBarrier
2026-10-23 12:21:20.418 EEST [3519408] STATEMENT: DROP DATABASE victim WITH
(FORCE)
2026-10-23 12:21:25.419 EEST [3519408] LOG: still waiting for backend with PID
3519403 to accept ProcSignalBarrier
2026-10-23 12:21:25.419 EEST [3519408] STATEMENT: DROP DATABASE victim WITH
(FORCE)
...
2026-10-23 12:22:10.441 EEST [3519408] LOG: still waiting for backend with PID
3519403 to accept ProcSignalBarrier
2026-10-23 12:22:10.441 EEST [3519408] STATEMENT: DROP DATABASE victim WITH
(FORCE)
2026-10-23 12:22:15.268 EEST [3519536] LOG: process 3519536 still waiting for AccessShareLock on relation 6100 of
database 0 after 1000.047 ms
2026-10-23 12:22:15.268 EEST [3519536] DETAIL: Process holding the lock:
3519408. Wait queue: 3519413, 3519423, 3519536.
2026-10-23 12:22:15.268 EEST [3519536] CONTEXT: waiting for AccessShareLock on
relation 6100 of database 0
2026-10-23 12:22:15.447 EEST [3519408] LOG: still waiting for backend with PID
3519403 to accept ProcSignalBarrier
2026-10-23 12:22:15.447 EEST [3519408] STATEMENT: DROP DATABASE victim WITH
(FORCE)
2026-10-23 12:22:18.412 EEST [3519386] LOG: received fast shutdown request
That is, with v3 applied, a backend still gets stuck.
Best regards,
Alexander Lakhin
Databricks
