The following bug has been logged online:

Bug reference: 1276
Logged by: Sean Chittenden

Email address: sean (AT) chittenden (DOT) org

PostgreSQL version: 8.0 Beta

Operating system: OS-X, FreeBSD

Description: Backend panics on SETVAL('..', 0)...

Details:

I haven't been able to reproduce this in a controlled way, but on a large
schema create in a single transaction, I was doing a SETVAL('foo_id_seq', 0)
and the backend was panicing, which seems broken. This is using HEAD from a
few hrs ago, but it's been going on for a while... I just stumbled across
this again while online and it jogged my memory. -sc

ERROR: setval: value 0 is out of bounds for sequence "foo_id_seq"
(1..9223372036854775807)
FATAL: block 0 of 1663/97972/98006 is still referenced (private 1, global
1)
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
connection to server was lost


dba@db: [local] 4030 2004-10-01 03:31:39 PDT LOG: statement: SELECT
SETVAL('schemaa.foo_id_seq'::TEXT, (SELECT MAX(id) FROM schemaa.foo));
dba@db: [local] 4030 2004-10-01 03:31:39 PDT ERROR: setval: value 0 is
out of bounds for sequence "foo_id_seq" (1..9223372036854775807)
dba@db: [local] 4030 2004-10-01 03:31:39 PDT FATAL: block 0 of
1663/97972/98006 is still referenced (private 1, global 1)
dba@db: [local] 4030 2004-10-01 03:31:39 PDT LOG: disconnection:
session time: 0:00:02.37 user=dba database=db host=[local] port=

--
Sean Chittenden


---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

"PostgreSQL Bugs List" <pgsql-bugs (AT) postgresql (DOT) org> writes:
Does that relation OID actually point to the sequence? I couldn't
duplicate this in desultory testing, so I think there's something
you didn't tell us.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

This bug can be closed. I was able to confirm that this bug has been
fixed by Tom's latest VACUUM fix. I was triggering this via a
pg_autovacuum that was running with a running with a 15sec sleep on a
schema load that was taking roughly 3 minutes (just the DDL). After
Tom's latest VACUUM commit, this bug does not appear to exist any more.
Thank you Tom! -sc

--
Sean Chittenden


---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster