On Tue, 13 Feb 2001, Mikheev, Vadim wrote:
> > Might it be, that pg_control is older than it should be ?
> > I mean, that the write to pg_control did not make it to disk,
> > but the checkpoint already completed (removed the logs) ?
>
> Well, WAL does *pg_fsync()* of pg_control before removing o
> Might it be, that pg_control is older than it should be ?
> I mean, that the write to pg_control did not make it to disk,
> but the checkpoint already completed (removed the logs) ?
Well, WAL does *pg_fsync()* of pg_control before removing old
logs, so it's only possible if Ryan run PG with -F
On Tue, 13 Feb 2001, Vadim Mikheev wrote:
> I don't remember why there is abort() in XLogFileOpen just before
> appropriate elog(STOP) there - I'll remove it in few moments, - but
> it's already obvious why open failed: there is no file with checkpoint
> record pointed by pg_control - data/pg_xlo
> > > #2 0x20dc71 in abort () from /lib/libc.so.6
> > > #3 0x8080495 in XLogFileOpen ()
> >
> > Hm. Evidently it's failing to open the xlog file, but the code is set
> > up in such a way that it dies before telling you why :-( Take a look
> > at XLogFileOpen in src/backend/access/transam/xlog
> > #2 0x20dc71 in abort () from /lib/libc.so.6
> > #3 0x8080495 in XLogFileOpen ()
>
> Hm. Evidently it's failing to open the xlog file, but the code is set
> up in such a way that it dies before telling you why :-( Take a look
> at XLogFileOpen in src/backend/access/transam/xlog.c and tweak
Ryan Kirkpatrick <[EMAIL PROTECTED]> writes:
> #2 0x20dc71 in abort () from /lib/libc.so.6
> #3 0x8080495 in XLogFileOpen ()
Hm. Evidently it's failing to open the xlog file, but the code is set
up in such a way that it dies before telling you why :-( Take a look
at XLogFileOpen in src/backen
On Mon, 12 Feb 2001, Ryan Kirkpatrick wrote:
> One other wrench to thrown into the works... The kernel on this
> machine is 2.2.18 with the patches listed at www.linuxraid.org applied. I
> have a feeling that the linux-security patches mentioned on that page may
> be giving pgsql heartburn
On Sun, 11 Feb 2001, Vadim Mikheev wrote:
> Please try to restart with option wal_debug = 1 so postmaster log
> will be more informative and send this log me.
I enabled 'wal_debug=1' via both the -c command line option and
(seperately) via ./data/postgresql.conf, as well as setting wal_d
> DEBUG: starting up
> DEBUG: database system was interrupted at 2001-02-11 04:08:12
> DEBUG: Checkpoint record at (0, 805076492)
> postmaster: reaping dead processes...
> Startup failed - abort
>
> And that is it, from running 'postmaster -D /usr/local/pgsql/data/'. I get
> the same thing each t
Ryan Kirkpatrick <[EMAIL PROTECTED]> writes:
> DEBUG: Checkpoint record at (0, 805076492)
> postmaster: reaping dead processes...
> Startup failed - abort
Hm. All we can tell from this is that the startup subprocess exited
with nonzero status. Did it leave a corefile? If so, what's the
stack t
Guess this what I get for attempting to use a beta version of
pgsql in a production system. :( My database server crashed (kernel
paging fault it looks like) and after reboot, postmaster refuses to start
up. There error it gives is:
DEBUG: starting up
DEBUG: database system was interrupt
11 matches
Mail list logo
