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: