Re: Minmax indexes

Thom Brown <thom@linux.com>

From: Thom Brown <thom@linux.com>
To: Jaime Casanova <jaime@2ndquadrant.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2013-09-17T13:43:31Z
Lists: pgsql-hackers
On 17 September 2013 14:37, Jaime Casanova <jaime@2ndquadrant.com> wrote:

> On Tue, Sep 17, 2013 at 3:30 AM, Thom Brown <thom@linux.com> wrote:
> > On 17 September 2013 07:20, Jaime Casanova <jaime@2ndquadrant.com>
> wrote:
> >>
> >> On Mon, Sep 16, 2013 at 3:47 AM, Thom Brown <thom@linux.com> wrote:
> >> > On 15 September 2013 01:14, Alvaro Herrera <alvherre@2ndquadrant.com>
> >> > wrote:
> >> >>
> >> >> Hi,
> >> >>
> >> >> Here's a reviewable version of what I've dubbed Minmax indexes.
> >> >>
> >> > Thanks for the patch, but I seem to have immediately hit a snag:
> >> >
> >> > pgbench=# CREATE INDEX minmaxtest ON pgbench_accounts USING minmax
> >> > (aid);
> >> > PANIC:  invalid xlog record length 0
> >> >
> >>
> >> fwiw, this seems to be triggered by ANALYZE.
> >> At least i can trigger it by executing ANALYZE on the table (attached
> >> is a stacktrace of a backend exhibiting the failure)
> >>
> >
> > I'm able to run ANALYSE manually without it dying:
> >
>
> try inserting some data before the ANALYZE, that will force a
> resumarization which is mentioned in the stack trace of the failure
>

I've tried inserting 1 row then ANALYSE and 10,000 rows then ANALYSE, and
in both cases there's no error.  But then trying to create the index again
results in my original error.

-- 
Thom

Commits

  1. Refactor per-page logic common to all redo routines to a new function.

  2. Reduce use of heavyweight locking inside hash AM.

  3. Scan the buffer pool just once, not once per fork, during relation drop.

  4. Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>