From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Andreas Seltenreich <seltenreich(at)gmx(dot)de> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [sqlsmith] PANIC: failed to add BRIN tuple |
Date: | 2016-05-23 16:41:14 |
Message-ID: | 20160523164114.GA391570@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andreas Seltenreich wrote:
> There was one instance of this PANIC when testing with the regression db
> of master at 50e5315.
>
> ,----
> | WARNING: specified item offset is too large
> | PANIC: failed to add BRIN tuple
> | server closed the connection unexpectedly
> `----
>
> It is reproducible with the query below on this instance only.
Hm, so this is an over-eager check. As I understand, what seems to have
happened is that the page was filled with up to 10 tuples, then tuples
0-8 were removed, probably moved to other pages. When this update runs,
it needs to update the remaining tuple, which is a normal thing for BRIN
to do. But BRIN doesn't want the item number to change, because it's
referenced from the "revmap"; so it removes the item and then wants to
insert it again. But bufpage.c is not accustomed to having callers want
to put items beyond what's the last currently used item plus one, so it
raises a warning and returns without doing the insert. This drives BRIN
crazy.
I tried simply removing the "return InvalidOffsetNumber" line from that
block (so that it still throws the warning but it does execute the index
insert), and everything seems to behave correctly. I suppose a simple
fix would be to add a flag to PageAddItem() and skip this block in that
case, but that would break the ABI in 9.5. I'm not real sure what's a
good fix yet. Maybe a new routine specific to the needs of BRIN is
called for.
I would also like to come up with a way to have this scenario be tested
by a new regression test.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-05-23 16:46:58 | Re: Latent cache flush hazard in RelationInitIndexAccessInfo |
Previous Message | Tom Lane | 2016-05-23 16:22:32 | Re: Parallel safety tagging of extension functions |