Re: [PG19] Promotion hangs behind a backend blocked on a stuck client

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