Re: [postgis-devel] CLUSTER in 8.3 on GIST indexes break

From: Mark Cave-Ayland <mark(dot)cave-ayland(at)siriusit(dot)co(dot)uk>
To: PostGIS Development Discussion <postgis-devel(at)postgis(dot)refractions(dot)net>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [postgis-devel] CLUSTER in 8.3 on GIST indexes break
Date: 2008-12-05 13:05:43
Message-ID: 49392727.6000302@siriusit.co.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Kevin,

Yeah I see exactly the same problem on 8.3.5 too, although it seems
random - what seems to happen is that sometimes the contents of the
temporary table disappears. I've attached a test script which causes the
error *some* of the time, although it tends to occur more often just
after the server has been restarted.

I've been invoking the attached script against a PostgreSQL
8.3.5/PostGIS 1.3.4 installation, and when the bug hits I see the
following psql output against a freshly restarted server:

postgis13=# \i /tmp/postgis-strange.sql
SELECT
CREATE INDEX
ANALYZE
count
-------
10000
(1 row)

CLUSTER
ANALYZE
count
-------
10000
(1 row)

postgis13=# \i /tmp/postgis-strange.sql
psql:/tmp/postgis-strange.sql:2: ERROR: relation "tmp" already exists
psql:/tmp/postgis-strange.sql:3: ERROR: relation "tmp_geom_idx" already
exists
ANALYZE
count
-------
10000
(1 row)

CLUSTER
ANALYZE
count
-------
0
(1 row)

postgis13=# \i /tmp/postgis-strange.sql
psql:/tmp/postgis-strange.sql:2: ERROR: relation "tmp" already exists
psql:/tmp/postgis-strange.sql:3: ERROR: relation "tmp_geom_idx" already
exists
ANALYZE
count
-------
0
(1 row)

CLUSTER
ANALYZE
count
-------
0
(1 row)

So in other words, the contents of the temporary table has just
disappeared :(

ATB,

Mark.

--
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063

Attachment Content-Type Size
postgis-strange.sql text/plain 291 bytes

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Merlin Moncure 2008-12-05 13:08:01 Re: ALTER composite type does not work, but ALTER TABLE which ROWTYPE is used as a type - works fine
Previous Message Bruce Momjian 2008-12-05 12:15:31 Re: In-place upgrade: catalog side