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 13:37:06 |
Message-ID: | CAJKUy5hqE=WdYve5TWVg7zDCUkV9HixJ5pWq7SxqWepTQNyQAQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
--
Jaime Casanova www.2ndQuadrant.com
Professional PostgreSQL: Soporte 24x7 y capacitación
Phone: +593 4 5107566 Cell: +593 987171157
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2013-09-17 13:38:11 | Re: New statistics for WAL buffer dirty writes |
Previous Message | Hannu Krosing | 2013-09-17 13:30:29 | Re: record identical operator |