The following bug has been logged online:

Bug reference: 2769
Logged by: Chris Jones
Email address: chris (AT) cjones (DOT) org
PostgreSQL version: 8.0.9
Operating system: NetBSD 2.0.2
Description: "invalid memory alloc request size <n>" on startup
Details:

After several uncontrolled reboots of the server, one of my hosted sites'
databases is giving an error on any attempt to connect to the DB. Trying to
distill this down to the simplest case possible, I stopped the postmaster
and ran postgres in standalone mode, with just that database. Setting the
debug level didn't seem to accomplish anything:

pgsql@maxine$ postgres -D data -d 5 drupal_dearslut
FATAL: invalid memory alloc request size 1095237632

The logs have only that 1 line in them, as well.

PostgreSQL 8.0.9 on i386--netbsdelf, compiled by GCC gcc (GCC) 3.3.3
(NetBSD nb3 20040520)

maxine$ uname -a
NetBSD maxine.cjones.org 2.0.2 NetBSD 2.0.2 (GENERIC) #0: Wed Mar 23
08:53:42 UTC 2005
jmc (AT) faith (DOT) netbsd.org:/home/builds/ab/netbsd-2-0-2-RELEASE/i386/200503220140Z
-obj/home/builds/ab/netbsd-2-0-2-RELEASE/src/sys/arch/i386/compile/GENERIC
i386

I used to be decent with gdb, so let me know if there's anything I can do as
far as backtraces, etc. Alternatively, if it's possible to get a consistent
dump of this DB, I could just upgrade to 8.1.

Chris

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly

"Chris Jones" <chris (AT) cjones (DOT) org> writes:
This looks like a problem of corrupt data in one of the system catalogs
or its indexes, but there's not enough info here to guess where.

Try setting a breakpoint at errfinish() and backtracing from there.

regards, tom lane

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

Chris Jones <chris (AT) cjones (DOT) org> writes:
Hmph. Apparently there is something wrong with the pg_internal.init
file in this database.

That was premature --- you could have just removed the broken init file
(which is merely a cache). I'm not sure how easy it'll be to identify
the problem with the cache file without an easy way to compare to valid
data, but if you want to send me the saved-off init file I'll take a
look. Which PG version is this again?

regards, tom lane

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