| From: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
|---|---|
| To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: pg19b1: stuck in LockBuffer |
| Date: | 2026-07-30 03:12:25 |
| Message-ID: | amrBGQel6AZeh8IN@pryzbyj2023 |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Jul 29, 2026 at 10:59:13PM -0400, Peter Geoghegan wrote:
> 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?
Very possibly. It does seem plausible that the patch mentioned by Chao
Li could explain this. Do you agree?
> 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).
Hmm, but that's not enabled by default, right ?
ts=# SHOW autovacuum_max_parallel_workers;
autovacuum_max_parallel_workers | 0
#20 lazy_scan_heap (vacrel=0x564cb9a4f208) at ./build/../src/backend/access/heap/vacuumlazy.c:1604
stream = <optimized out>
next_fsm_block_to_vacuum = 0
initprog_val = {1, 343, 67108864}
rel_pages = <optimized out>
blkno = 342
orig_eager_scan_success_limit = <optimized out>
vmbuffer = 2622
initprog_index = {0, 1, 5}
stream = <optimized out>
rel_pages = <optimized out>
blkno = <optimized out>
next_fsm_block_to_vacuum = <optimized out>
orig_eager_scan_success_limit = <optimized out>
vmbuffer = <optimized out>
initprog_index = <optimized out>
initprog_val = <optimized out>
__func__ = "lazy_scan_heap"
buf = <optimized out>
page = <optimized out>
was_eager_scanned = <optimized out>
ndeleted = <optimized out>
has_lpdead_items = <optimized out>
per_buffer_data = <optimized out>
vm_page_frozen = <optimized out>
got_cleanup_lock = <optimized out>
__errno_location = <optimized out>
freespace = <optimized out>
(gdb) p *vacrel
$1 = {rel = 0x7f437c8d9ca0, indrels = 0x564cb9a4f9a0, nindexes = 2, bstrategy = 0x564cb9a9c0e0, pvs = 0x0, aggressive = false, skipwithvm = true, consider_bypass_optimization = true, do_index_vacuuming = true,
do_index_cleanup = true, do_rel_truncate = true, cutoffs = {relfrozenxid = 3578361690, relminmxid = 131919937, OldestXmin = 3579704350, OldestMxact = 131921394, FreezeLimit = 3529704350, MultiXactCutoff = 126921394},
vistest = 0x564cb82960f0 <GlobalVisCatalogRels>, NewRelfrozenXid = 3579704350, NewRelminMxid = 131921394, skippedallvis = true, dbname = 0x564cb9a4f170 "ts", relnamespace = 0x564cb9a4f110 "pg_catalog",
relname = 0x564cb9a4f410 "pg_attribute", indname = 0x564cb9a4fe90 "pg_attribute_relid_attnam_index", blkno = 4294967295, offnum = 0, phase = VACUUM_ERRCB_PHASE_VACUUM_INDEX, verbose = false, dead_items = 0x564cb9a4fa38,
dead_items_info = 0x564cb9a4fa20, rel_pages = 343, scanned_pages = 66, eager_scanned_pages = 0, removed_pages = 0, new_frozen_tuple_pages = 0, new_all_visible_pages = 0, new_all_visible_all_frozen_pages = 0,
new_all_frozen_pages = 0, lpdead_item_pages = 29, missed_dead_pages = 0, nonempty_pages = 342, new_rel_tuples = 17608, new_live_tuples = 17608, indstats = 0x564cb9a4f9f8, num_index_scans = 0, num_dead_items_resets = 0,
total_dead_items_bytes = 0, worker_usage = {vacuum = {nplanned = 0, nlaunched = 0}, cleanup = {nplanned = 0, nlaunched = 0}}, tuples_deleted = 766, tuples_frozen = 0, lpdead_items = 904, live_tuples = 2900,
recently_dead_tuples = 0, missed_dead_tuples = 0, current_block = 342, next_unskippable_block = 342, next_unskippable_eager_scanned = false, next_unskippable_vmbuffer = 0, next_eager_scan_region_start = 4294967295,
eager_scan_remaining_successes = 0, eager_scan_max_fails_per_region = 0, eager_scan_remaining_fails = 0}
(gdb) p *vacrel->rel
$2 = {rd_locator = {spcOid = 1663, dbOid = 59856131, relNumber = 120237976}, rd_smgr = 0x564cb9a68d40, rd_refcnt = 2, rd_backend = -1, rd_islocaltemp = false, rd_isnailed = true, rd_isvalid = true, rd_indexvalid = true,
rd_statvalid = false, rd_createSubid = 0, rd_newRelfilelocatorSubid = 0, rd_firstRelfilelocatorSubid = 0, rd_droppedSubid = 0, rd_rel = 0x7f437c8d9ea8, rd_att = 0x7f437c8d9fb0, rd_id = 1249, rd_lockInfo = {lockRelId = {
relId = 1249, dbId = 59856131}}, rd_rules = 0x0, rd_rulescxt = 0x0, trigdesc = 0x0, rd_rsdesc = 0x0, rd_fkeylist = 0x0, rd_fkeyvalid = false, rd_partkey = 0x0, rd_partkeycxt = 0x0, rd_partdesc = 0x0, rd_pdcxt = 0x0,
rd_partdesc_nodetached = 0x0, rd_pddcxt = 0x0, rd_partdesc_nodetached_xmin = 0, rd_partcheck = 0x0, rd_partcheckvalid = false, rd_partcheckcxt = 0x0, rd_indexlist = 0x564cb9a3d9e8, rd_pkindex = 2659,
rd_ispkdeferrable = false, rd_replidindex = 0, rd_statlist = 0x0, rd_attrsvalid = false, rd_keyattr = 0x0, rd_pkattr = 0x0, rd_idattr = 0x0, rd_hotblockingattr = 0x0, rd_summarizedattr = 0x0, rd_pubdesc = 0x0,
rd_options = 0x0, rd_amhandler = 3, rd_tableam = 0x564cb825d920 <heapam_methods>, rd_index = 0x0, rd_indextuple = 0x0, rd_indexcxt = 0x0, rd_indam = 0x0, rd_opfamily = 0x0, rd_opcintype = 0x0, rd_support = 0x0,
rd_supportinfo = 0x0, rd_indoption = 0x0, rd_indexprs = 0x0, rd_indpred = 0x0, rd_exclops = 0x0, rd_exclprocs = 0x0, rd_exclstrats = 0x0, rd_indcollation = 0x0, rd_opcoptions = 0x0, rd_amcache = 0x0, rd_fdwroutine = 0x0,
rd_toastoid = 0, pgstat_enabled = true, pgstat_info = 0x564cb9a913a0}
--
Justin
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Justin Pryzby | 2026-07-30 03:12:49 | Re: pg19b1: stuck in LockBuffer |
| Previous Message | Ashutosh Bapat | 2026-07-30 03:01:58 | Re: Fix missing space before WHERE in `GRAPH_TABLE` deparse |