can't startup PG-8.0.3
Hello !
I can't startup PostgreSQL 8.0.3 on my server. The OS is
# uname -a
FreeBSD 5.4-RC3 #1: Mon Apr 25 11:58:52 KRAST 2005
I have experience with PostgreSQL 7.x, and I can't figure out why this
happen. PG didn't
say anything meaningful, that can point me why he did not start.
I have a command
su - pgsql -c '/usr/local/pgsql/bin/postmaster -d 5 -D
/usr/local/pgsql/data'
and a last output of it is
...
%DEBUG: TZ "SystemV/PST8" scores 0: at 1074099600 2004-01-14 09:00:00
std versus 2004-01-15 00:00:00 std
%DEBUG: TZ "SystemV/YST9" scores 0: at 1074099600 2004-01-14 08:00:00
std versus 2004-01-15 00:00:00 std
%DEBUG: TZ "SystemV/HST10" scores 0: at 1074099600 2004-01-14 07:00:00
std versus 2004-01-15 00:00:00 std
%DEBUG: Reject TZ "Mideast/Riyadh87": uses leap seconds
%DEBUG: Reject TZ "Mideast/Riyadh88": uses leap seconds
%DEBUG: Reject TZ "Mideast/Riyadh89": uses leap seconds
%DEBUG: postmaster: PostmasterMain: initial environ dump:
%DEBUG: -----------------------------------------
%DEBUG: TERM=xterm
%DEBUG: SHELL=/usr/local/bin/bash
%DEBUG: USER=pgsql
%DEBUG: PGLIB=/usr/local/lib
%DEBUG: FTP_PASSIVE_MODE=YES
%DEBUG: MAIL=/var/mail/pgsql
%DEBUG:
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin:/usr/local/pgsql/bin
%DEBUG: BLOCKSIZE=K
%DEBUG: PWD=/usr/local/pgsql
%DEBUG: SHLVL=1
%DEBUG: HOME=/usr/local/pgsql
%DEBUG: PGDATA=/usr/local/pgsql/data
%DEBUG: _=/usr/local/pgsql/bin/postmaster
%DEBUG: PGSYSCONFDIR=/usr/local/pgsql/etc
%DEBUG: -----------------------------------------
I even tries to use ktrace(1) :
ktrace su - pgsql -c '/usr/local/pgsql/bin/postmaster -d 5 -D
/usr/local/pgsql/data'
and a last lines of kdump is
80040 su CALL close(0x3)
80040 su RET close 0
80040 su CALL seteuid(0)
80040 su RET seteuid 0
80040 su CALL setegid(0x46)
80040 su RET setegid 0
80040 su CALL sigaction(0x2,0xbfbfe764,0xbfbfe744)
80040 su RET sigaction 0
80040 su CALL sigaction(0x3,0xbfbfe764,0xbfbfe724)
80040 su RET sigaction 0
80040 su CALL sigaction(0xd,0xbfbfe764,0xbfbfe704)
80040 su RET sigaction 0
80040 su CALL sigaction(0x12,0xbfbfe764,0)
80040 su RET sigaction 0
80040 su CALL pipe
80040 su RET pipe 3
80040 su CALL fork
80040 su RET fork 80041/0x138a9
80040 su CALL sigaction(0x16,0xbfbfe764,0)
80040 su RET sigaction 0
80040 su CALL close(0x3)
80040 su RET close 0
80040 su CALL setpgid(0x138a9,0x138a9)
80040 su RET setpgid 0
80040 su CALL ioctl(0x2,TIOCSPGRP,0xbfbfe660)
80040 su RET ioctl 0
80040 su CALL close(0x4)
80040 su RET close 0
80040 su CALL sigaction(0xd,0xbfbfe704,0)
80040 su RET sigaction 0
80040 su CALL wait4(0x138a9,0xbfbfe6e8,0x2,0)
80040 su RET wait4 80041/0x138a9
80040 su CALL getpgrp
80040 su RET getpgrp 6052/0x17a4
80040 su CALL ioctl(0x2,TIOCSPGRP,0xbfbfe660)
80040 su RET ioctl 0
80040 su CALL sigprocmask(0x1,0x2806baa0,0xbfbfe4d0)
80040 su RET sigprocmask 0
80040 su CALL sigprocmask(0x3,0x2806bab0,0)
80040 su RET sigprocmask 0
80040 su CALL sigprocmask(0x1,0x2806baa0,0xbfbfe4d0)
80040 su RET sigprocmask 0
80040 su CALL munmap(0x28181000,0x2000)
80040 su RET munmap 0
80040 su CALL sigprocmask(0x3,0x2806bab0,0)
80040 su RET sigprocmask 0
80040 su CALL sigprocmask(0x1,0x2806baa0,0xbfbfe4f0)
80040 su RET sigprocmask 0
80040 su CALL sigprocmask(0x3,0x2806bab0,0)
80040 su RET sigprocmask 0
80040 su CALL sigprocmask(0x1,0x2806baa0,0xbfbfe4f0)
80040 su RET sigprocmask 0
80040 su CALL munmap(0x2816c000,0x2000)
80040 su RET munmap 0
80040 su CALL munmap(0x2816e000,0x9000)
80040 su RET munmap 0
80040 su CALL munmap(0x28177000,0xa000)
80040 su RET munmap 0
80040 su CALL sigprocmask(0x3,0x2806bab0,0)
80040 su RET sigprocmask 0
80040 su CALL sigprocmask(0x1,0x2806baa0,0xbfbfe510)
80040 su RET sigprocmask 0
80040 su CALL sigprocmask(0x3,0x2806bab0,0)
80040 su RET sigprocmask 0
80040 su CALL sigprocmask(0x1,0x2806baa0,0xbfbfe510)
80040 su RET sigprocmask 0
80040 su CALL munmap(0x2816a000,0x2000)
80040 su RET munmap 0
80040 su CALL sigprocmask(0x3,0x2806bab0,0)
80040 su RET sigprocmask 0
80040 su CALL sigprocmask(0x1,0x2806baa0,0xbfbfe530)
80040 su RET sigprocmask 0
80040 su CALL sigprocmask(0x3,0x2806bab0,0)
80040 su RET sigprocmask 0
80040 su CALL sigprocmask(0x1,0x2806baa0,0xbfbfe530)
80040 su RET sigprocmask 0
80040 su CALL munmap(0x28168000,0x2000)
80040 su RET munmap 0
80040 su CALL sigprocmask(0x3,0x2806bab0,0)
80040 su RET sigprocmask 0
80040 su CALL sigprocmask(0x1,0x2806baa0,0xbfbfe550)
80040 su RET sigprocmask 0
80040 su CALL sigprocmask(0x3,0x2806bab0,0)
80040 su RET sigprocmask 0
80040 su CALL sigprocmask(0x1,0x2806baa0,0xbfbfe550)
80040 su RET sigprocmask 0
80040 su CALL munmap(0x28166000,0x2000)
80040 su RET munmap 0
80040 su CALL sigprocmask(0x3,0x2806bab0,0)
80040 su RET sigprocmask 0
80040 su CALL sigprocmask(0x1,0x2806baa0,0xbfbfe530)
80040 su RET sigprocmask 0
80040 su CALL sigprocmask(0x3,0x2806bab0,0)
80040 su RET sigprocmask 0
80040 su CALL sigprocmask(0x1,0x2806baa0,0xbfbfe530)
80040 su RET sigprocmask 0
80040 su CALL munmap(0x28183000,0x4000)
80040 su RET munmap 0
80040 su CALL munmap(0x28187000,0x18000)
80040 su RET munmap 0
80040 su CALL munmap(0x2819f000,0x5000)
80040 su RET munmap 0
80040 su CALL sigprocmask(0x3,0x2806bab0,0)
80040 su RET sigprocmask 0
80040 su CALL sigprocmask(0x1,0x2806baa0,0xbfbfe550)
80040 su RET sigprocmask 0
80040 su CALL sigprocmask(0x3,0x2806bab0,0)
80040 su RET sigprocmask 0
80040 su CALL sigprocmask(0x1,0x2806baa0,0xbfbfe550)
80040 su RET sigprocmask 0
80040 su CALL munmap(0x281a4000,0x3000)
80040 su RET munmap 0
80040 su CALL sigprocmask(0x3,0x2806bab0,0)
80040 su RET sigprocmask 0
80040 su CALL sigprocmask(0x1,0x2806baa0,0xbfbfe550)
80040 su RET sigprocmask 0
80040 su CALL sigprocmask(0x3,0x2806bab0,0)
80040 su RET sigprocmask 0
80040 su RET sigprocmask 0
80040 su CALL munmap(0x281a7000,0x2000)
80040 su RET munmap 0
80040 su CALL sigprocmask(0x3,0x2806bab0,0)
80040 su RET sigprocmask 0
80040 su CALL exit(0)
and this didn't help...
The configure script for PG was:
./configure \
--enable-locale \
--enable-recode \
--with-pgport=6543 \
--enable-cassert \
--with-perl \
--enable-odbc
# ./postgres --version
postgres (PostgreSQL) 8.0.3
I also tried to use pg_ctl to startup PG instance, but it silently stops:
could not start postmaster
Thanks a lot for any helpful info.
--
Ruslan A Dautkhanov
Ruslan A Dautkhanov <rusland@scn.ru> writes:
I have experience with PostgreSQL 7.x, and I can't figure out why this
happen. PG didn't
say anything meaningful, that can point me why he did not start.
That's fairly unusual --- I can't think of any places where the
postmaster will exit without printing *some* complaint.
I have a command
su - pgsql -c '/usr/local/pgsql/bin/postmaster -d 5 -D
/usr/local/pgsql/data'
Shouldn't there be an & or something in there? Seems like that will
leave the su command blocked waiting for the postmaster to exit,
which of course it should not.
I even tries to use ktrace(1) :
ktrace su - pgsql -c '/usr/local/pgsql/bin/postmaster -d 5 -D
/usr/local/pgsql/data'
That won't tell you anything --- the trace will only trace what "su" does.
Better to su to pgsql and ktrace the postmaster directly.
regards, tom lane
Hello !
Tom Lane wrote:
I have a command
su - pgsql -c '/usr/local/pgsql/bin/postmaster -d 5 -D
/usr/local/pgsql/data'Shouldn't there be an & or something in there? Seems like that will
leave the su command blocked waiting for the postmaster to exit,
which of course it should not.
I try to use &, this did not help.
I even tries to use ktrace(1) :
ktrace su - pgsql -c '/usr/local/pgsql/bin/postmaster -d 5 -D
/usr/local/pgsql/data'That won't tell you anything --- the trace will only trace what "su" does.
Better to su to pgsql and ktrace the postmaster directly.
Yes, you're right. The ktrace dump for postmaster process:
su - pgsql -c 'ktrace /usr/local/pgsql/bin/postmaster -i -d 5 -D
/usr/local/pgsql/data' :
...
86611 postgres RET write 44/0x2c
86611 postgres CALL gettimeofday(0xbfbfd5a8,0)
86611 postgres RET gettimeofday 0
86611 postgres CALL getpid
86611 postgres RET getpid 86611/0x15253
86611 postgres CALL sendto(0x5,0xbfbfda80,0x60,0,0,0)
86611 postgres GIO fd 5 wrote 96 bytes
"<135>Jun 27 11:02:02 postgres[86611]: [569-1] %DEBUG:
-----------------------------------------"
86611 postgres RET sendto 96/0x60
86611 postgres CALL write(0x2,0x82eb128,0x33)
86611 postgres GIO fd 2 wrote 51 bytes
"%DEBUG: -----------------------------------------
"
86611 postgres RET write 51/0x33
86611 postgres CALL fork
86611 postgres RET fork 86612/0x15254
86611 postgres CALL exit(0)
I'll keep try to startup PostgreSQL 8.0.3... Thanks
--
Ruslan A Dautkhanov
Tom Lane wrote:
Ruslan A Dautkhanov <rusland@scn.ru> writes:
I have experience with PostgreSQL 7.x, and I can't figure out why this
happen. PG didn't
say anything meaningful, that can point me why he did not start.That's fairly unusual --- I can't think of any places where the
postmaster will exit without printing *some* complaint.
# ./pg_controldata /usr/local/pgsql/data
pg_control version number: 74
Catalog version number: 200411041
Database system identifier: 4786296063829923563
Database cluster state: in production
pg_control last modified: О©╫О©╫О©╫О©╫О©╫, 22 О©╫О©╫О©╫О©╫ 2005 О©╫. 03:12:28
Current log file ID: 0
Next log file segment: 13
Latest checkpoint location: 0/C1DB058
Prior checkpoint location: 0/C0E47BC
Latest checkpoint's REDO location: 0/C1DB058
Latest checkpoint's UNDO location: 0/0
Latest checkpoint's TimeLineID: 1
Latest checkpoint's NextXID: 133213
Latest checkpoint's NextOID: 492366
Time of latest checkpoint: О©╫О©╫О©╫О©╫О©╫, 22 О©╫О©╫О©╫О©╫ 2005 О©╫. 03:12:28
Database block size: 8192
Blocks per segment of large relation: 131072
Bytes per WAL segment: 16777216
Maximum length of identifiers: 64
Maximum number of function arguments: 32
Date/time type storage: floating-point numbers
Maximum length of locale name: 128
LC_COLLATE: ru_RU.KOI8-R
LC_CTYPE: ru_RU.KOI8-R
Please note different values in "Latest checkpoint location" and "Prior
checkpoint location" - is this mean
that DB shutted down abnormally and some uncommited data exists? Maybe
Postgres can't commit
this changes?
Btw, before this version I use PG 8.0.2 and after this I install 8.0.3,
that can't startup... :/
Maybe 8.0.3 conflict with DB created in 8.0.2 ?
Thanks a lot for your comments.
--
Ruslan A Dautkhanov
Ruslan A Dautkhanov <rusland@scn.ru> writes:
Please note different values in "Latest checkpoint location" and "Prior
checkpoint location" - is this mean
that DB shutted down abnormally and some uncommited data exists?
No; indeed, if they were the same *then* I would worry.
regards, tom lane