|From:||Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>|
|To:||Jaime Casanova <jaime(at)2ndquadrant(dot)com>|
|Cc:||Thom Brown <thom(at)linux(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: Minmax indexes|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Jaime Casanova wrote:
> 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
Thanks. This was a trivial off-by-one bug; fixed in the attached patch.
While studying it, I noticed that I was also failing to notice extension
of the fork by another process. I have tried to fix that also in the
current patch, but I'm afraid that a fully robust solution for this will
involve having a cached fork size in the index's relcache entry -- just
like we have smgr_vm_nblocks. In fact, since the revmap fork is
currently reusing the VM forknum, I might even be able to use the same
variable to keep track of the fork size. But I don't really like this
bit of reusing the VM forknum for revmap, so I've refrained from
extending that assumption into further code for the time being.
There was also a bug that we would try to initialize a revmap page twice
during recovery, if two backends thought they needed to extend it; that
would cause the data written by the first extender to be lost.
This patch applies on top of the two previous incremental patches. I
will send a full patch later, including all those fixes and the fix for
the opr_sanity regression test.
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
|Next Message||Kevin Grittner||2013-09-24 22:46:37||Re: record identical operator|
|Previous Message||Bruce Momjian||2013-09-24 21:36:58||Re: unaccent module - two params function should be immutable|