Re: BUG #19755: Server-wide hang: DROP DATABASE waits forever for ProcSignalBarrier while VACUUM waits on pg_databas

From: shihao zhong <zhong950419(at)gmail(dot)com>
To: anncalla(at)163(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #19755: Server-wide hang: DROP DATABASE waits forever for ProcSignalBarrier while VACUUM waits on pg_databas
Date: 2026-10-15 04:31:29
Message-ID: CAGRkXqS0p1sCOLg5DQ+8cAc2RCPc2KyNyR_tkY1NT2O0hG1JdQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hi Ann,

Thanks for filing the bug. Surprisingly we still have that kind of 3 way
deadloads.
I guess this is because not a lots of people running these command together.

You don't need a restart to get out, though. Canceling the VACUUM FULL
or the DROP DATABASE from a session that is already connected breaks
the cycle, and so does kill -INT on one of them from the shell.

The attached patch locks pg_database before taking
WrapLimitsVacuumLock. The scan of pg_database still runs under the
LWLock, so the race fixed by 566372b3d64 stays fixed.

Thanks,
Shihao

Attachment Content-Type Size
v1-0001-Lock-pg_database-before-WrapLimitsVacuumLock-in-v.patch application/octet-stream 1.9 KB

In response to

Browse pgsql-bugs by date

  From Date Subject
Previous Message Manu 2026-10-15 04:08:19 Re: use-after-free in jsonb_set_lax()