New version of contrib-intarray is ready !

From: Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgman(at)candle(dot)pha(dot)pa(dot)us>, <pgsql-hackers(at)postgresql(dot)org>
Subject: New version of contrib-intarray is ready !
Date: 2001-03-19 14:42:43
Message-ID: Pine.GSO.4.33.0103191739310.1001-100000@ra.sai.msu.su
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

New version of contrib-intarray is available from
http://www.sai.msu.su/~megera/postgres/gist/code/7.1/contrib-intarray.tar.gz

>From README.intarray:

March 19, 2001
1. Added support for toastable keys
2. Improved split algorithm for intbig (selection speedup is about 30%)

Regards,
Oleg

On Mon, 19 Mar 2001, Oleg Bartunov wrote:

> I just returned from vacation and identified the problem.
> We'll fix it.
>
> Regards,
> Oleg
> On Sun, 18 Mar 2001, Tom Lane wrote:
>
> > I wrote:
> > > I did this, also reinstalled the include-file changes I had made, and
> > > then spent several fruitless hours trying to find why the "intbig" index
> > > operators fail selftest here (on HP-PA). I suppose it's a portability
> > > problem, since presumably they pass for Oleg ... but I don't see it.
> >
> > Further experimentation shows that intbig fails selftest on ALL
> > platforms under 7.1. I see the problem: the intarray operators are
> > mostly unprepared to cope with TOASTed input arrays. In particular,
> > _intbig_union() generates an erroneous "null" result for a compressed
> > input array, leading to completely incorrect GiST index trees in the
> > self-test example.
> >
> > A somewhat-related error in this code is that some routines feel free
> > to scribble on their input. This is tres uncool, because they may be
> > scribbling on disk buffers. Example:
> >
> >
> > regression=# create table foo(f1 int4[]);
> > CREATE
> > regression=# insert into foo values ('{10,1,2,1,4}');
> > INSERT 150265 1
> > regression=# select * from foo;
> > f1
> > --------------
> > {10,1,2,1,4}
> > (1 row)
> >
> > regression=# select * from foo where f1 && '{4}';
> > f1
> > --------------
> > {1,1,2,4,10}
> > (1 row)
> >
> > regression=# select * from foo;
> > f1
> > --------------
> > {1,1,2,4,10}
> > (1 row)
> >
> >
> > And you thought SELECT was a read-only operation ...
> >
> > I do not have time to work on this stuff now, but as it stands the
> > contrib/intarray code is unusable in 7.1. Unless Oleg can find the
> > time to fix these issues before release, I will recommend that we
> > not ship contrib/intarray in 7.1.
> >
> > regards, tom lane
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 5: Have you checked our extensive FAQ?
> >
> > http://www.postgresql.org/users-lounge/docs/faq.html
> >
>
> Regards,
> Oleg
> _____________________________________________________________
> Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
> Sternberg Astronomical Institute, Moscow University (Russia)
> Internet: oleg(at)sai(dot)msu(dot)su, http://www.sai.msu.su/~megera/
> phone: +007(095)939-16-83, +007(095)939-23-83
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html
>

Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg(at)sai(dot)msu(dot)su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2001-03-19 14:59:03 Re: Re: Small bug in pg_dump
Previous Message Bruce Momjian 2001-03-19 14:29:01 Re: Allowing WAL fsync to be done via O_SYNC