Re: BRIN indexes - TRAP: BadArgument - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: BRIN indexes - TRAP: BadArgument
Date
Msg-id 20141110203911.GH1791@alvin.alvh.no-ip.org
Whole thread Raw
In response to Re: BRIN indexes - TRAP: BadArgument  (Fujii Masao <masao.fujii@gmail.com>)
Responses Re: BRIN indexes - TRAP: BadArgument  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
Fujii Masao wrote:

> I got the following PANIC error in the standby server when I set up
> the replication servers and ran "make installcheck". Note that I was
> repeating the manual CHECKPOINT every second while "installcheck"
> was running. Without the checkpoints, I could not reproduce the
> problem. I'm not sure if CHECKPOINT really triggers this problem, though.
> Anyway BRIN seems to have a problem around its WAL replay.

Hm, I think I see what's happening.  The xl_brin_update record
references two buffers, one which is target for the updated tuple and
another which is the revmap buffer.  When the update target buffer is
being first used we set the INIT bit which removes the buffer reference
from the xlog record; in that case, if the revmap buffer is first being
modified after the prior checkpoint, that revmap buffer receives backup
block number 0; but the code hardcodes it as 1 on the expectation that
the buffer that's target for the update will receive 0.  The attached
patch should fix this.

I cannot reproduce the issue after applying this patch, can you please
confirm that it fixes the issue for you as well?

--
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: row_to_json bug with index only scans: empty keys!
Next
From: Stephen Frost
Date:
Subject: Re: pg_background (and more parallelism infrastructure patches)