BUG #1276: Backend panics on SETVAL('..', 0)...
The following bug has been logged online:
Bug reference: 1276
Logged by: Sean Chittenden
Email address: sean@chittenden.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
"PostgreSQL Bugs List" <pgsql-bugs@postgresql.org> writes:
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)
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
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
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
Import Notes
Reply to msg id not found: 34C64ABC-1663-11D9-9F57-000A95C705DC@chittenden.org