Re: 7.2.1 segfaults.

Stephen Amadei <amadei(at)dandy(dot)net> writes:
> #0 0x255843 in strncpy (s1=0xbfffead0 "n\013", s2=0x8213414 "n\013",
> n=4294967292) at ../sysdeps/generic/strncpy.c:82
> #1 0x81516ab in GetRawDatabaseInfo ()
> #2 0x81511fb in InitPostgres ()

Hmm. It looks like GetRawDatabaseInfo is reading a zero for the VARSIZE
of datpath, and then computing -4 (which strncpy will take as a huge
unsigned value) as the string length to copy. You could try applying
a patch like this, in src/backend/utils/misc/database.c (about line
225 in current sources):

/* Found it; extract the OID and the database path. */
*db_id = tup.t_data->t_oid;
pathlen = VARSIZE(&(tup_db->datpath)) - VARHDRSZ;
+ if (pathlen < 0)
+ pathlen = 0; /* pure paranoia */
if (pathlen >= MAXPGPATH)
pathlen = MAXPGPATH - 1; /* pure paranoia */
strncpy(path, VARDATA(&(tup_db->datpath)), pathlen);
path[pathlen] = '\0';

However this really shouldn't be needed; I'm wondering whether the
database's row in pg_database has been clobbered somehow. If so,
it probably won't get much further before dying.

Two questions: does the same thing happen for all available databases?
Have you tried to create a database with a nonstandard location
(nondefault datpath)?

regards, tom lane