Re: Minmax indexes

From: Jaime Casanova <jaime(at)2ndquadrant(dot)com>
To: Thom Brown <thom(at)linux(dot)com>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Minmax indexes
Date: 2013-09-17 16:04:40
Message-ID: CAJKUy5jSS3g48R33uxd36x=ndf4t-gwqfkg1m-Ab1_vofgu6MQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Sep 17, 2013 at 8:43 AM, Thom Brown <thom(at)linux(dot)com> wrote:
> On 17 September 2013 14:37, Jaime Casanova <jaime(at)2ndquadrant(dot)com> wrote:
>>
>> On Tue, Sep 17, 2013 at 3:30 AM, Thom Brown <thom(at)linux(dot)com> wrote:
>> > On 17 September 2013 07:20, Jaime Casanova <jaime(at)2ndquadrant(dot)com>
>> > wrote:
>> >>
>> >> On Mon, Sep 16, 2013 at 3:47 AM, Thom Brown <thom(at)linux(dot)com> wrote:
>> >> > On 15 September 2013 01:14, Alvaro Herrera <alvherre(at)2ndquadrant(dot)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.
>

Ok

So, please confirm if this is the pattern you are following:

CREATE TABLE t1(i int);
INSERT INTO t1 SELECT generate_series(1, 10000);
CREATE INDEX idx1 ON t1 USING minmax (i);

if that, then the attached stack trace (index_failure_thom.txt) should
correspond to the failure you are looking.

My test was slightly different:

CREATE TABLE t1(i int);
CREATE INDEX idx1 ON t1 USING minmax (i);
INSERT INTO t1 SELECT generate_series(1, 10000);
ANALYZE t1;

and the failure happened in a different time, in resumarization
(attached index_failure_jcm.txt)

but in the end, both failures seems to happen for the same reason: a
record of length 0... at XLogInsert time

#4 XLogInsert at xlog.c:966
#5 mmSetHeapBlockItemptr at mmrevmap.c:169
#6 mm_doinsert at minmax.c:1410

actually, if you create a temp table both tests works fine

--
Jaime Casanova www.2ndQuadrant.com
Professional PostgreSQL: Soporte 24x7 y capacitación
Phone: +593 4 5107566 Cell: +593 987171157

Attachment Content-Type Size
index_failure_jcm.txt text/plain 3.9 KB
index_failure_thom.txt text/plain 5.3 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2013-09-17 16:29:51 Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE
Previous Message Fujii Masao 2013-09-17 15:56:17 Re: pg_stat_statements: calls under-estimation propagation