New version of contrib-intarray is ready ! - Mailing list pgsql-hackers

From Oleg Bartunov
Subject New version of contrib-intarray is ready !
Date
Msg-id Pine.GSO.4.33.0103191739310.1001-100000@ra.sai.msu.su
Whole thread Raw
In response to Re: new version of contrib-intarray  (Oleg Bartunov <oleg@sai.msu.su>)
Responses Re: New version of contrib-intarray is ready !  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: New version of contrib-intarray is ready !  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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@sai.msu.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@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83





pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Allowing WAL fsync to be done via O_SYNC
Next
From: Bruce Momjian
Date:
Subject: Re: Re: Small bug in pg_dump