Thread: PostgreSQL 9.1.0 bug?

I think I've found a bug either in PostgreSQL 9.1.0 or in the ip4r
package (version 1.05).  Since the problematic behavior occurs on
different tables and on different servers, it should be relatively easy
to reproduce:

CREATE TABLE foo (
  id serial NOT NULL,
  range ip4r NOT NULL,
  PRIMARY KEY (id)
);

Now populate this table with >2M rows where the range values don't
overlap.  Ensure this by doing

ALTER TABLE foo
ADD CONSTRAINT foo_range_ix
EXCLUDE USING gist (range WITH &&);

After a while PostgreSQL will begin to eat all your main memory and then crash.

Harald Fuchs <hari.fuchs@gmail.com> writes:
> I think I've found a bug either in PostgreSQL 9.1.0 or in the ip4r
> package (version 1.05).

Good catch --- gistendscan is forgetting to free so->giststate.
But it seems just as broken in 9.0 and probably before ...

            regards, tom lane

In article <21641.1316159544@sss.pgh.pa.us>,
Tom Lane <tgl@sss.pgh.pa.us> writes:

> Harald Fuchs <hari.fuchs@gmail.com> writes:
>> I think I've found a bug either in PostgreSQL 9.1.0 or in the ip4r
>> package (version 1.05).

> Good catch --- gistendscan is forgetting to free so->giststate.

Confirmed - adding a "pfree(so->giststate)" solves my problem.  Thanks
for the quick fix!