Re: 9.2.1 & index-only scans : abnormal heap fetches after VACUUM FULL - Mailing list pgsql-hackers

From Jaime Casanova
Subject Re: 9.2.1 & index-only scans : abnormal heap fetches after VACUUM FULL
Date
Msg-id CAJKUy5jUgCFxz=zdZ5esqcpKmunTpA+-Hj_s5hRD8ep8B4TOYg@mail.gmail.com
Whole thread Raw
In response to Re: 9.2.1 & index-only scans : abnormal heap fetches after VACUUM FULL  (Bruce Momjian <bruce@momjian.us>)
Responses Re: 9.2.1 & index-only scans : abnormal heap fetches after VACUUM FULL
Re: 9.2.1 & index-only scans : abnormal heap fetches after VACUUM FULL
List pgsql-hackers
On Tue, Dec 3, 2013 at 11:25 AM, Bruce Momjian <bruce@momjian.us> wrote:
>
> Is everyone else OK with this approach?  Updated patch attached.
>

Hi,

I started to look at this patch and i found that it fails an assertion
as soon as you run a VACUUM FULL after a lazy VACUUM even if those are
on unrelated relations. For example in an assert-enabled build with
the regression database run:

VACUUM customer;
[... insert here whatever commands you like or nothing at all ...]
VACUUM FULL tenk1;

TRAP: FailedAssertion("!(InRecovery || ( ((void) ((bool) ((!
assert_enabled) || ! (!((heapBuf) <= NBuffers && (heapBuf) >=
-NLocBuffer)) || (ExceptionalCondition("!((heapBuf) <= NBuffers &&
(heapBuf) >= -NLocBuffer)", ("FailedAssertion"), "visibilitymap.c",
260), 0)))), (heapBuf) != 0 ))", File: "visibilitymap.c", Line: 260)
LOG:  server process (PID 25842) was terminated by signal 6: Aborted
DETAIL:  Failed process was running: vacuum FULL customer;
LOG:  terminating any other active server processes

trace:
(gdb) bt
#0  0x00007f9a3d00d475 in *__GI_raise (sig=<optimized out>) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00007f9a3d0106f0 in *__GI_abort () at abort.c:92
#2  0x0000000000777597 in ExceptionalCondition (   conditionName=conditionName@entry=0x7cd3b8 "!(InRecovery || (
((void) ((bool) ((! assert_enabled) || ! (!((heapBuf) <= NBuffers &&
(heapBuf) >= -NLocBuffer)) || (ExceptionalCondition(\"!((heapBuf) <=
NBuffers && (heapBuf) >= -NLocBuffer)\", (\"Fai"...,
errorType=errorType@entry=0x7b0730 "FailedAssertion",   fileName=fileName@entry=0x7cd105 "visibilitymap.c",
lineNumber=lineNumber@entry=260) at assert.c:54
#3  0x00000000004a7d99 in visibilitymap_set
(rel=rel@entry=0x7f9a3da56a00, heapBlk=heapBlk@entry=0,
heapBuf=heapBuf@entry=0, recptr=recptr@entry=0, vmBuf=220,   cutoff_xid=2) at visibilitymap.c:260
#4  0x00000000004a33e5 in update_page_vm (relation=0x7f9a3da56a00,
page=page@entry=0x1868b18 "", blkno=0) at rewriteheap.c:702
#5  0x00000000004a3668 in raw_heap_insert
(state=state@entry=0x1849e98, tup=tup@entry=0x184f208) at
rewriteheap.c:641
#6  0x00000000004a3b8b in rewrite_heap_tuple
(state=state@entry=0x1849e98, old_tuple=old_tuple@entry=0x1852a50,
new_tuple=new_tuple@entry=0x184f208)   at rewriteheap.c:433
#7  0x000000000055c373 in reform_and_rewrite_tuple
(tuple=tuple@entry=0x1852a50,
oldTupDesc=oldTupDesc@entry=0x7f9a3da4d350,   newTupDesc=newTupDesc@entry=0x7f9a3da599a8,
values=values@entry=0x1852f40, isnull=isnull@entry=0x184f920 "",
newRelHasOids=1 '\001',   rwstate=rwstate@entry=0x1849e98) at cluster.c:1670

--
Jaime Casanova         www.2ndQuadrant.com
Professional PostgreSQL: Soporte 24x7 y capacitación
Phone: +593 4 5107566         Cell: +593 987171157



pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: Standalone synchronous master
Next
From: Florian Pflug
Date:
Subject: Re: Standalone synchronous master