Re: pg19b1: stuck in LockBuffer

On Wed, Jul 29, 2026 at 10:48 PM Justin Pryzby <pryzby(at)telsasoft(dot)com> wrote:
>
> Several backends are stuck at:
> #7 0x0000564cb7a14def in LockBuffer (mode=BUFFER_LOCK_SHARE, buffer=14934) at ./build/../src/include/storage/bufmgr.h:339
>
> process 2124119 #7 0x0000564cb7a14def in LockBuffer (mode=BUFFER_LOCK_SHARE, buffer=14934) at ./build/../src/include/storage/bufmgr.h:339
> process 2099630 #7 0x0000564cb7a13909 in LockBuffer (mode=BUFFER_LOCK_EXCLUSIVE, buffer=14934) at ./build/../src/include/storage/bufmgr.h:339
> process 2391859 #7 0x0000564cb7a13909 in LockBuffer (mode=BUFFER_LOCK_EXCLUSIVE, buffer=14934) at ./build/../src/include/storage/bufmgr.h:339
> process 2131445 #7 0x0000564cb7a13909 in LockBuffer (mode=BUFFER_LOCK_EXCLUSIVE, buffer=14934) at ./build/../src/include/storage/bufmgr.h:339
> process 2131446 #7 0x0000564cb7a13909 in LockBuffer (mode=BUFFER_LOCK_EXCLUSIVE, buffer=14934) at ./build/../src/include/storage/bufmgr.h:339
> process 2103100 #7 0x0000564cb7a13909 in LockBuffer (mode=BUFFER_LOCK_EXCLUSIVE, buffer=14934) at ./build/../src/include/storage/bufmgr.h:339
>
> The earliest stuck backend (by query_start) is:
> 2124119 | 2026-07-29 20:00:39.925199-05 | | BufferShared | autovacuum worker | autovacuum: VACUUM ANALYZE pg_catalog.pg_attribute
>
> This is 19~beta1-1~20260603.2015.g378668d50b4.pgdg12+1 on debian12 / linux 6.1.0-21-amd64
> pg_upgraded on Jun 3.

It looks like you're testing commit 378668d5. I wonder if this was a
bug that a later commit already fixed?

I suspect this is actually an issue with parallel autovacuum. Can you
show "bt full" output? I'd be particularly interested in seeing the
contents of vacrel, from lazy_scan_heap (dereference the pointer so we
can see what all its fields hold).

--
Peter Geoghegan