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
From | Date | Subject | |
---|---|---|---|
postgresql : | roberto_vanoncini | 2000-08-22 16:33:38 | postgresql : 스포츠 토토 |
Previous Message | Philip Poles | 2000-08-22 15:12:34 | Re: Creation of 10000's of empty table segments and more... |