Re: PANIC in GIN code

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Heikki <hlinnaka(at)iki(dot)fi>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PANIC in GIN code
Date: 2015-06-28 22:12:15
Message-ID: CAMkU=1xUSStjv+YYiFRBpr6p7C-Brngxm8-OMpkDqvLVa3qkKw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Jun 28, 2015 at 12:31 PM, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
wrote:

> On 06/26/2015 10:53 PM, Jeff Janes wrote:
>
>> On Fri, Jun 26, 2015 at 11:40 AM, Heikki Linnakangas <hlinnaka(at)iki(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2015-06-28 22:21:21 Re: Solaris testers wanted for strxfrm() behavior
Previous Message Thomas Munro 2015-06-28 22:05:19 Re: Solaris testers wanted for strxfrm() behavior