Re: 7.2.1 segfaults.

Stephen Amadei <amadei@dandy.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