Re: Minmax indexes

Jaime Casanova <jaime@2ndquadrant.com>

From: Jaime Casanova <jaime@2ndquadrant.com>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Thom Brown <thom@linux.com>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2013-09-18T07:02:40Z
Lists: pgsql-hackers
On Tue, Sep 17, 2013 at 4:03 PM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
> Thom Brown wrote:
>
> Thanks for testing.
>
>> 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
>
> Silly mistake I had already made in another patch.  Here's an
> incremental patch which fixes this bug.  Apply this on top of previous
> minmax-1.patch.
>
> I also renumbered the duplicate OID pointed out by Peter, and fixed the
> two compiler warnings reported by Jaime.
>
> Note you'll need to re-initdb in order to get the right catalog entries.
>

Hi,

Found another problem with the this steps:

create table t1 (i int);
create index idx_t1_i on t1 using minmax(i);
insert into t1 select generate_series(1, 2000000);
ERROR:  could not read block 1 in file "base/12645/16397_vm": read
only 0 of 8192 bytes
STATEMENT:  insert into t1 select generate_series(1, 2000000);
ERROR:  could not read block 1 in file "base/12645/16397_vm": read
only 0 of 8192 bytes

After that, i keep receiving these messages (when autovacuum tries to
vacuum this table):

ERROR:  could not truncate file "base/12645/16397_vm" to 2 blocks:
it's only 1 blocks now
CONTEXT:  automatic vacuum of table "postgres.public.t1"
ERROR:  could not truncate file "base/12645/16397_vm" to 2 blocks:
it's only 1 blocks now
CONTEXT:  automatic vacuum of table "postgres.public.t1"

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


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>