Re: pg19b1: stuck in LockBuffer - Mailing list pgsql-hackers

From Chao Li
Subject Re: pg19b1: stuck in LockBuffer
Date
Msg-id 8B21D594-1F2D-441C-B86D-4036AEA08B9B@gmail.com
Whole thread
In response to pg19b1: stuck in LockBuffer  (Justin Pryzby <pryzby@telsasoft.com>)
List pgsql-hackers

> On Jul 30, 2026, at 10:48, Justin Pryzby <pryzby@telsasoft.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.
>
> (gdb) bt
> #0  __futex_abstimed_wait_common (futex_word=futex_word@entry=0x7f4389e3fd80, expected=expected@entry=0,
clockid=clockid@entry=0,abstime=abstime@entry=0x0, private=<optimized out>, cancel=cancel@entry=true) 
>    at ./nptl/futex-internal.c:103
> #1  0x00007f438d6981bb in __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x7f4389e3fd80,
expected=expected@entry=0,clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=<optimized out>) 
>    at ./nptl/futex-internal.c:139
> #2  0x00007f438d6a2f0f in do_futex_wait (sem=sem@entry=0x7f4389e3fd80, abstime=0x0, clockid=0) at
./nptl/sem_waitcommon.c:111
> #3  0x00007f438d6a2fa0 in __new_sem_wait_slow64 (sem=sem@entry=0x7f4389e3fd80, abstime=0x0, clockid=0) at
./nptl/sem_waitcommon.c:183
> #4  0x00007f438d6a3009 in __new_sem_wait (sem=sem@entry=0x7f4389e3fd80) at ./nptl/sem_wait.c:42
> #5  0x0000564cb7cc3ca2 in PGSemaphoreLock (sema=0x7f4389e3fd80) at ./build/src/backend/port/pg_sema.c:320
> #6  0x0000564cb7d3e9c0 in BufferLockAcquire (buffer=<optimized out>, buf_hdr=0x7f437f064a40, mode=BUFFER_LOCK_SHARE)
at./build/../src/backend/storage/buffer/bufmgr.c:5997 
> #7  0x0000564cb7a14def in LockBuffer (mode=BUFFER_LOCK_SHARE, buffer=14934) at
./build/../src/include/storage/bufmgr.h:339
> #8  _bt_lockbuf (access=1, buf=14934, rel=<optimized out>) at ./build/../src/backend/access/nbtree/nbtpage.c:1070
> #9  _bt_getbuf (access=1, blkno=97, rel=<optimized out>) at ./build/../src/backend/access/nbtree/nbtpage.c:858
> #10 _bt_rightsib_halfdeadflag (leafrightsib=97, rel=<optimized out>) at
./build/../src/backend/access/nbtree/nbtpage.c:1791
> #11 _bt_mark_page_halfdead (stack=0x564cb9afc908, leafbuf=3597, heaprel=0x7f437c8d9ca0, rel=<optimized out>) at
./build/../src/backend/access/nbtree/nbtpage.c:2160
> #12 _bt_pagedel (rel=<optimized out>, leafbuf=3597, vstate=0x7fff720f3ed0) at
./build/../src/backend/access/nbtree/nbtpage.c:2031
> #13 0x0000564cb7a1d5c6 in btvacuumpage (vstate=vstate@entry=0x7fff720f3ed0, buf=<optimized out>) at
./build/../src/backend/access/nbtree/nbtree.c:1712
> #14 0x0000564cb7a1de18 in btvacuumscan (info=info@entry=0x7fff720f40e0, stats=stats@entry=0x564cb9a4f128,
callback=callback@entry=0x564cb7b77b80<vac_tid_reaped>, callback_state=callback_state@entry=0x564cb9a4fa38,  
>    cycleid=<optimized out>) at ./build/../src/backend/access/nbtree/nbtree.c:1366
> #15 0x0000564cb7a1dfdf in btbulkdelete (info=0x7fff720f40e0, stats=0x564cb9a4f128, callback=0x564cb7b77b80
<vac_tid_reaped>,callback_state=0x564cb9a4fa38) at ./build/../src/backend/access/nbtree/nbtree.c:1138 
> #16 0x0000564cb7b7a982 in vac_bulkdel_one_index (ivinfo=ivinfo@entry=0x7fff720f40e0, istat=istat@entry=0x0,
dead_items=<optimizedout>, dead_items_info=0x564cb9a4fa20) at ./build/../src/backend/commands/vacuum.c:2667 
> #17 0x0000564cb7a07b8d in lazy_vacuum_one_index (vacrel=0x564cb9a4f208, reltuples=<optimized out>, istat=0x0,
indrel=<optimizedout>) at ./build/../src/backend/access/heap/vacuumlazy.c:3041 
> #18 lazy_vacuum_all_indexes (vacrel=vacrel@entry=0x564cb9a4f208) at
./build/../src/backend/access/heap/vacuumlazy.c:2536
> #19 0x0000564cb7a0a01f in lazy_vacuum (vacrel=0x564cb9a4f208) at ./build/../src/backend/access/heap/vacuumlazy.c:2454
> #20 lazy_scan_heap (vacrel=0x564cb9a4f208) at ./build/../src/backend/access/heap/vacuumlazy.c:1604
> #21 heap_vacuum_rel (rel=<optimized out>, params=<optimized out>, bstrategy=<optimized out>) at
./build/../src/backend/access/heap/vacuumlazy.c:881
> #22 0x0000564cb7b7827b in table_relation_vacuum (bstrategy=0x564cb9a9c0e0, params=0x7fff720f4870, rel=0x7f437c8d9ca0)
at./build/../src/include/access/tableam.h:1780 
> #23 vacuum_rel (relid=1249, relation=<optimized out>, params=..., bstrategy=bstrategy@entry=0x564cb9a9c0e0,
isTopLevel=isTopLevel@entry=true)at ./build/../src/backend/commands/vacuum.c:2310 
> #24 0x0000564cb7b7981c in vacuum (relations=<optimized out>, params=params@entry=0x564cb9a93e80,
bstrategy=bstrategy@entry=0x564cb9a9c0e0,vac_context=vac_context@entry=0x564cb9ac4090,
isTopLevel=isTopLevel@entry=true)
>    at ./build/../src/backend/commands/vacuum.c:633
> #25 0x0000564cb7cc7ff1 in autovacuum_do_vac_analyze (bstrategy=<optimized out>, tab=0x564cb9a93e78) at
./build/../src/backend/postmaster/autovacuum.c:3367
> #26 do_autovacuum () at ./build/../src/backend/postmaster/autovacuum.c:2517
> #27 0x0000564cb7cc8557 in AutoVacWorkerMain (startup_data=<optimized out>, startup_data_len=<optimized out>) at
./build/../src/backend/postmaster/autovacuum.c:1637
> #28 0x0000564cb7ccdb64 in postmaster_child_launch (child_type=child_type@entry=B_AUTOVAC_WORKER, child_slot=404,
startup_data=startup_data@entry=0x0,startup_data_len=startup_data_len@entry=0,  
>    client_sock=client_sock@entry=0x0) at ./build/../src/backend/postmaster/launch_backend.c:268
> #29 0x0000564cb7ccfb6d in StartChildProcess (type=B_AUTOVAC_WORKER) at
./build/../src/backend/postmaster/postmaster.c:4030
> #30 0x0000564cb7cd1e7c in StartAutovacuumWorker () at ./build/../src/backend/postmaster/postmaster.c:4094
> #31 process_pm_pmsignal () at ./build/../src/backend/postmaster/postmaster.c:3851
> #32 ServerLoop () at ./build/../src/backend/postmaster/postmaster.c:1721
> #33 0x0000564cb7cd3044 in PostmasterMain (argc=argc@entry=11, argv=argv@entry=0x564cb9959180) at
./build/../src/backend/postmaster/postmaster.c:1415
> #34 0x0000564cb79ac67c in main (argc=11, argv=0x564cb9959180) at ./build/../src/backend/main/main.c:231
>
> I don't need to restart this immediately, so might be able to collect
> more info.
>
> --
> Justin
>
>

It seems a later build should have fixed this issue, see [1]. Your build is from June 3 (378668d50b4), the fix was
pushedon June 30. 

[1] https://git.postgresql.org/cgit/postgresql.git/commit/?id=8d85cb889a395f08d58e59c31a67f199f0fc25c3

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/







Attachment

pgsql-hackers by date:

Previous
From: Xuneng Zhou
Date:
Subject: Re: Implement waiting for wal lsn replay: reloaded
Next
From: Peter Geoghegan
Date:
Subject: Re: pg19b1: stuck in LockBuffer