Re: PANIC: wrong buffer passed to visibilitymap_clear - Mailing list pgsql-hackers

From Andres Freund
Subject Re: PANIC: wrong buffer passed to visibilitymap_clear
Date
Msg-id 20210409233044.g3ucnqp5yy67wkd2@alap3.anarazel.de
Whole thread Raw
In response to Re: PANIC: wrong buffer passed to visibilitymap_clear  (Peter Geoghegan <pg@bowt.ie>)
List pgsql-hackers
Hi,

On 2021-04-09 16:27:12 -0700, Peter Geoghegan wrote:
> They're both VACUUM ANALYZE. They must be, because the calls to
> visibilitymap_clear PANIC (they don't ERROR) -- the failing
> visibilitymap_clear() call must occur inside a critical section, and
> all such calls are made within heapam.c (only VACUUM ANALYZE uses a
> transaction and does writes). It cannot be the two calls to
> visibilitymap_clear() inside vacuumlazy.c.

There's a stacktrace at the bottom of the spurfowl report:

======-=-====== stack trace: pgsql.build/src/test/regress/tmp_check/data/core ======-=-======
[New LWP 24172]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `postgres: autovacuum worker regression                                        '.
Program terminated with signal SIGABRT, Aborted.
#0  0x00007f77a7967428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
54    ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
#0  0x00007f77a7967428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#1  0x00007f77a796902a in __GI_abort () at abort.c:89
#2  0x000000000095cf8d in errfinish (filename=<optimized out>, filename@entry=0x9c3fa0 "visibilitymap.c",
lineno=lineno@entry=155,funcname=funcname@entry=0x9c41c0 <__func__.13853> "visibilitymap_clear") at elog.c:680
 
#3  0x0000000000501498 in visibilitymap_clear (rel=rel@entry=0x7f77a96d2d28, heapBlk=<optimized out>, buf=buf@entry=0,
flags=flags@entry=3'\\003') at visibilitymap.c:155
 
#4  0x00000000004e6380 in heap_update (relation=relation@entry=0x7f77a96d2d28, otid=otid@entry=0x2c0394c,
newtup=newtup@entry=0x2c03948,cid=0, crosscheck=crosscheck@entry=0x0, wait=wait@entry=true, tmfd=0x7ffe119d2c20,
lockmode=0x7ffe119d2c1c)at heapam.c:3993
 
#5  0x00000000004e7d70 in simple_heap_update (relation=relation@entry=0x7f77a96d2d28, otid=otid@entry=0x2c0394c,
tup=tup@entry=0x2c03948)at heapam.c:4211
 
#6  0x00000000005811a9 in CatalogTupleUpdate (heapRel=0x7f77a96d2d28, otid=0x2c0394c, tup=0x2c03948) at indexing.c:309
#7  0x00000000005efc32 in update_attstats (relid=16928, inh=inh@entry=false, natts=natts@entry=1,
vacattrstats=vacattrstats@entry=0x2b3c030)at analyze.c:1746
 
#8  0x00000000005f264a in update_attstats (vacattrstats=0x2b3c030, natts=1, inh=false, relid=<optimized out>) at
analyze.c:589
#9  do_analyze_rel (onerel=onerel@entry=0x7f77a95c1070, params=params@entry=0x2aba36c, va_cols=va_cols@entry=0x0,
acquirefunc=<optimizedout>, relpages=33, inh=inh@entry=false, in_outer_xact=false, elevel=13) at analyze.c:589
 
#10 0x00000000005f2d8d in analyze_rel (relid=<optimized out>, relation=<optimized out>, params=params@entry=0x2aba36c,
va_cols=0x0,in_outer_xact=<optimized out>, bstrategy=<optimized out>) at analyze.c:261
 
#11 0x0000000000671721 in vacuum (relations=0x2b492b8, params=params@entry=0x2aba36c, bstrategy=<optimized out>,
bstrategy@entry=0x2aba4e8,isTopLevel=isTopLevel@entry=true) at vacuum.c:478
 
#12 0x000000000048f02d in autovacuum_do_vac_analyze (bstrategy=0x2aba4e8, tab=0x2aba368) at autovacuum.c:3316
#13 do_autovacuum () at autovacuum.c:2537
#14 0x0000000000779d76 in AutoVacWorkerMain (argv=0x0, argc=0) at autovacuum.c:1715
#15 0x0000000000779e79 in StartAutoVacWorker () at autovacuum.c:1500
#16 0x0000000000788324 in StartAutovacuumWorker () at postmaster.c:5539
#17 sigusr1_handler (postgres_signal_arg=<optimized out>) at postmaster.c:5243
#18 <signal handler called>
#19 0x00007f77a7a2f5b3 in __select_nocancel () at ../sysdeps/unix/syscall-template.S:84
#20 0x0000000000788668 in ServerLoop () at postmaster.c:1701
#21 0x000000000078a187 in PostmasterMain (argc=argc@entry=8, argv=argv@entry=0x2a408c0) at postmaster.c:1409
#22 0x0000000000490e48 in main (argc=8, argv=0x2a408c0) at main.c:209
$1 = {si_signo = 6, si_errno = 0, si_code = -6, _sifields = {_pad = {24172, 1001, 0 <repeats 26 times>}, _kill =
{si_pid= 24172, si_uid = 1001}, _timer = {si_tid = 24172, si_overrun = 1001, si_sigval = {sival_int = 0, sival_ptr =
0x0}},_rt = {si_pid = 24172, si_uid = 1001, si_sigval = {sival_int = 0, sival_ptr = 0x0}}, _sigchld = {si_pid = 24172,
si_uid= 1001, si_status = 0, si_utime = 0, si_stime = 0}, _sigfault = {si_addr = 0x3e900005e6c, _addr_lsb = 0,
_addr_bnd= {_lower = 0x0, _upper = 0x0}}, _sigpoll = {si_band = 4299262287468, si_fd = 0}}}
 

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: PANIC: wrong buffer passed to visibilitymap_clear
Next
From: Andres Freund
Date:
Subject: Re: PANIC: wrong buffer passed to visibilitymap_clear