Re: Creation of 10000's of empty table segments and more...

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Philip Poles" <philip(at)surfen(dot)net>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: Creation of 10000's of empty table segments and more...
Date: 2000-08-22 15:24:14
Message-ID: 6969.966957854@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

> Also, there are no core files lying around anywhere, which is somewhat
> surprising.

Hm. On some platforms, processes started from system startup scripts
run with "ulimit coredumpsize" set to 0, which prevents coredumps.
You may need to start the postmaster manually with a normal ulimit
before you will get a corefile.

> Does it make any difference that I compiled with a BLCKSZ of 32768 and
> NAMEDATALEN of 64?

In theory, no ...

> All I do have is the intact contents of the database directory of the
> problem database. Is there any way to move this to another
> installation so that I can have a look at it, and maybe get you a core
> dump or at least a detailed log on another machine?

If you have the entire $PGDATA directory, you can copy it to another
identically-configured machine. Or you can leave it where it is and
start up a test postmaster in it (just specify -D pointing at the data
dir, and select a port number other than the standard 5432 with -p).
If you do that, just remember to specify the special port number when
connecting with psql (use -p, or set environment variable PGPORT).

A coredump backtrace should help, especially if you recompile with -g
first.

> Also, would upgrading to 7.0.2 help,

Possibly, but it's hard to tell until we know more. I'd suggest leaving
your installation alone until we have more info.

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message roberto_vanoncini 2000-08-22 16:33:38 HP-Ux v.11 release
Previous Message Philip Poles 2000-08-22 15:12:34 Re: Creation of 10000's of empty table segments and more...