Re: PANIC in GIN code - Mailing list pgsql-hackers

From Jeff Janes
Subject Re: PANIC in GIN code
Date
Msg-id CAMkU=1xUSStjv+YYiFRBpr6p7C-Brngxm8-OMpkDqvLVa3qkKw@mail.gmail.com
Whole thread Raw
In response to Re: PANIC in GIN code  (Heikki Linnakangas <hlinnaka@iki.fi>)
Responses Re: PANIC in GIN code
List pgsql-hackers
On Sun, Jun 28, 2015 at 12:31 PM, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
On 06/26/2015 10:53 PM, Jeff Janes wrote:
On Fri, Jun 26, 2015 at 11:40 AM, Heikki Linnakangas <hlinnaka@iki.fi>
wrote:

The page is being split (that's evident from "info=48" above).
ginPlaceToPage calls GinNewBuffer, which calls GetFreeIndexPage(). That
finds a page that can be recycled, and marks it as used.
RecordUsedIndexPage calls MarkBufferDirtyHint(), which in turn calls
XLogSaveBufferForHint() to create a full-page image record of the page.
That calls XLogBeginInsert() + XLogInsert(), and leaves the
begininsert_called == false.

If you had assertions enabled, you'd see the assertion in
XLogBeginInsert() to fail.

I'll look into that over the weekend..

Committed a fix, fortunately it was easy to rearrange that code so that XLogBeginInsert() is called after the GinNewBuffer() calls. Can you verify that it fixed your test case, please?

Now I'm getting a different error, with or without checksums.

ERROR:  invalid page in block 0 of relation base/16384/16420
CONTEXT:  automatic vacuum of table "jjanes.public.foo"

16420 is the gin index.  I can't even get the page with pageinspect:

jjanes=# SELECT * FROM get_raw_page('foo_text_array_idx', 0);
ERROR:  invalid page in block 0 of relation base/16384/16420

This is the last few gin entries from pg_xlogdump


rmgr: Gin         len (rec/tot):      0/  3893, tx:          0, lsn: 0/77270E90, prev 0/77270E68, desc: VACUUM_PAGE , blkref #0: rel 1663/16384/16420 blk 27 FPW
rmgr: Gin         len (rec/tot):      0/  3013, tx:          0, lsn: 0/77272080, prev 0/77272058, desc: VACUUM_PAGE , blkref #0: rel 1663/16384/16420 blk 6904 FPW
rmgr: Gin         len (rec/tot):      0/  3093, tx:          0, lsn: 0/77272E08, prev 0/77272DE0, desc: VACUUM_PAGE , blkref #0: rel 1663/16384/16420 blk 1257 FPW
rmgr: Gin         len (rec/tot):      8/  4662, tx:  318119897, lsn: 0/77A2CF10, prev 0/77A2CEC8, desc: INSERT_LISTPAGE , blkref #0: rel 1663/16384/16420 blk 22184
rmgr: Gin         len (rec/tot):     88/   134, tx:  318119897, lsn: 0/77A2E188, prev 0/77A2E160, desc: UPDATE_META_PAGE , blkref #0: rel 1663/16384/16420 blk 0


And the metapage is mostly zeros:
 
head -c 8192 /tmp/data2_invalid_page/base/16384/16420 | od
0000000 000000 000000 161020 073642 000000 000000 000000 000000
0000020 000000 000000 000000 000000 053250 000000 053250 000000
0000040 006140 000000 000001 000000 000001 000000 000000 000000
0000060 031215 000000 000452 000000 000000 000000 000000 000000
0000100 025370 000000 000000 000000 000002 000000 000000 000000
0000120 000000 000000 000000 000000 000000 000000 000000 000000
*
0020000


Thanks,

Jeff

pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Solaris testers wanted for strxfrm() behavior
Next
From: Peter Geoghegan
Date:
Subject: Re: Solaris testers wanted for strxfrm() behavior