Обсуждение: Postgres 7.4.5 fails with Cygwin 1.5.18-1 (core dump)
An old W2K installation now fails with core dump after postmaster. A new WXP installation fails in the same way. Cygserver is running as a service and is started Postmaster core dumps when run. Running postmaster with debug gives: bash-3.00$ postmaster -d 5 DEBUG: postmaster: PostmasterMain: initial environ dump: DEBUG: ----------------------------------------- DEBUG: HOMEPATH=\Documents and Settings\adb DEBUG: TERM=cygwin DEBUG: PROCESSOR_IDENTIFIER=x86 Family 15 Model 47 Stepping 2, AuthenticAMD DEBUG: WINDIR=C:\WINDOWS DEBUG: USERDOMAIN=ACONCAGUA DEBUG: OS=Windows_NT DEBUG: !::=::\ DEBUG: COMMONPROGRAMFILES=C:\Program Files\Common Files DEBUG: PROCESSOR_LEVEL=15 DEBUG: PATH=/usr/bin:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS: /cygdrive/c/WINDOWS/System32/Wbem: /cygdrive/c/Program Files/ATI Technologies/ATI Control Panel DEBUG: FP_NO_HOST_CHECK=NO DEBUG: PWD=/usr/bin DEBUG: SYSTEMDRIVE=C: DEBUG: CYGWIN=server ntsec tty DEBUG: USERPROFILE=C:\Documents and Settings\adb DEBUG: CLIENTNAME=Console DEBUG: LOGONSERVER=\\ACONCAGUA DEBUG: PROCESSOR_ARCHITECTURE=x86 DEBUG: !C:=C:\Documents and Settings\adb DEBUG: SHLVL=1 DEBUG: HOME=/home/adb DEBUG: PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.sh DEBUG: HOMEDRIVE=C: DEBUG: PROMPT=$P$G DEBUG: COMSPEC=C:\WINDOWS\system32\cmd.exe DEBUG: TMP=/cygdrive/c/DOCUME~1/adb/LOCALS~1/Temp DEBUG: SYSTEMROOT=C:\WINDOWS DEBUG: LOGNAME=adb DEBUG: PROCESSOR_REVISION=2f02 DEBUG: PGDATA=/var/postgresql/data DEBUG: PROGRAMFILES=C:\Program Files DEBUG: NUMBER_OF_PROCESSORS=1 DEBUG: SESSIONNAME=Console DEBUG: COMPUTERNAME=ACONCAGUA DEBUG: _=/usr/bin/postmaster DEBUG: TZ=FLEST-2FLEST-3,M3.5.0/3,M10.5.0/4 <a few other environ vars snipped> DEBUG: ----------------------------------------- DEBUG: searching PATH for executable DEBUG: found "/usr/bin/postgres" using PATH DEBUG: invoking IpcMemoryCreate(size=9469952) Segmentation fault (core dumped) The sygserver log shows plenty of semctl ops, but no obvious errors. I've used the default cygserver.conf, but have since played around with the settings. By setting all the kern shm and sem settings to the max, the cygserver fails to start and then becomes unstoppable (as reported by someone else). Any ideas? Antony
Antony <adb <at> teamware.com> writes: I have tried the 19th August snapshot of cygwin dll, which is the earliest on the snapshot page, but that reports as incompatible. Another postee reports successfully using the 9th Aug snapshot. Anyone know where I can get that? Regards Antony
Antony schrieb: > An old W2K installation now fails with core dump after postmaster. > A new WXP installation fails in the same way. > > Cygserver is running as a service and is started > > Postmaster core dumps when run. > > Running postmaster with debug gives: > > bash-3.00$ postmaster -d 5 > DEBUG: postmaster: PostmasterMain: initial environ dump: > DEBUG: ----------------------------------------- > DEBUG: HOMEPATH=\Documents and Settings\adb > DEBUG: TERM=cygwin > DEBUG: PROCESSOR_IDENTIFIER=x86 Family 15 Model 47 Stepping 2, > AuthenticAMD > DEBUG: WINDIR=C:\WINDOWS > DEBUG: USERDOMAIN=ACONCAGUA > DEBUG: OS=Windows_NT > DEBUG: !::=::\ > DEBUG: COMMONPROGRAMFILES=C:\Program Files\Common Files > DEBUG: PROCESSOR_LEVEL=15 > DEBUG: > PATH=/usr/bin:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS: > /cygdrive/c/WINDOWS/System32/Wbem: > /cygdrive/c/Program Files/ATI Technologies/ATI Control Panel > DEBUG: FP_NO_HOST_CHECK=NO > DEBUG: PWD=/usr/bin > DEBUG: SYSTEMDRIVE=C: > DEBUG: CYGWIN=server ntsec tty > DEBUG: USERPROFILE=C:\Documents and Settings\adb > DEBUG: CLIENTNAME=Console > DEBUG: LOGONSERVER=\\ACONCAGUA > DEBUG: PROCESSOR_ARCHITECTURE=x86 > DEBUG: !C:=C:\Documents and Settings\adb > DEBUG: SHLVL=1 > DEBUG: HOME=/home/adb > DEBUG: PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.sh > DEBUG: HOMEDRIVE=C: > DEBUG: PROMPT=$P$G > DEBUG: COMSPEC=C:\WINDOWS\system32\cmd.exe > DEBUG: TMP=/cygdrive/c/DOCUME~1/adb/LOCALS~1/Temp > DEBUG: SYSTEMROOT=C:\WINDOWS > DEBUG: LOGNAME=adb > DEBUG: PROCESSOR_REVISION=2f02 > DEBUG: PGDATA=/var/postgresql/data > DEBUG: PROGRAMFILES=C:\Program Files > DEBUG: NUMBER_OF_PROCESSORS=1 > DEBUG: SESSIONNAME=Console > DEBUG: COMPUTERNAME=ACONCAGUA > DEBUG: _=/usr/bin/postmaster > DEBUG: TZ=FLEST-2FLEST-3,M3.5.0/3,M10.5.0/4 > > <a few other environ vars snipped> > > DEBUG: ----------------------------------------- > DEBUG: searching PATH for executable > DEBUG: found "/usr/bin/postgres" using PATH > DEBUG: invoking IpcMemoryCreate(size=9469952) > Segmentation fault (core dumped) > > The sygserver log shows plenty of semctl ops, but no obvious errors. > > I've used the default cygserver.conf, but have since played around with the > settings. By setting all the kern shm and sem settings to the max, the > cygserver fails to start and then becomes unstoppable (as reported by > someone else). > This seems to be a problem of cygwin 1.5.18. Snapshots of the upcoming 1.5.19 solved for some people on this list their problem to run PostgreSQL. See the mail from Jeff Lu from 2005-08-12. -- Roland Walter phone: +49 (0) 22 25 / 88 2-41 1 MOSAIC SOFTWARE AG fax: +49 (0) 22 25 / 88 2-20 1 Am Pannacker 3 mailto: rwa (at) mosaic-ag (dot) com D-53340 Meckenheim http://www.mosaic-ag.com ------- L E G A L D I S C L A I M E R --------- Die Informationen in dieser Nachricht sind vertraulich und ausschliesslich fuer den Adressaten bestimmt. Kenntnisnahme durch Dritte ist unzulaessig. Die Erstellung von Kopien oder das Weiterleiten an weitere, nicht originaere und benannte Adressaten ist nicht vorgesehen und kann ungesetzlich sein. Die Meinungen in dieser Nachricht stellen lediglich die Meinungen des Senders dar. Falls Sie vermuten, dass diese Nachricht veraendert wurde, setzen Sie sich mit dem Absender in Verbindung. Der Absender uebernimmt ohne weitere Ueberpruefung keine Verantwortung fuer die Richtigkeit und Vollstaendigkeit des Inhalts. Unbefugte Empfaenger werden gebeten, die Vertraulichkeit der Nachricht zu wahren und den Absender sofort ueber einen Uebertragungsfehler zu informieren. ------------------------------------------------------
Roland Walter schrieb: > > This seems to be a problem of cygwin 1.5.18. Snapshots of the upcoming > 1.5.19 solved for some people on this list their problem to run > PostgreSQL. See the mail from Jeff Lu from 2005-08-12. The author of the mail was VT Student. But you had found it already. -- Roland Walter phone: +49 (0) 22 25 / 88 2-41 1 MOSAIC SOFTWARE AG fax: +49 (0) 22 25 / 88 2-20 1 Am Pannacker 3 mailto: rwa (at) mosaic-ag (dot) com D-53340 Meckenheim http://www.mosaic-ag.com ------- L E G A L D I S C L A I M E R --------- Die Informationen in dieser Nachricht sind vertraulich und ausschliesslich fuer den Adressaten bestimmt. Kenntnisnahme durch Dritte ist unzulaessig. Die Erstellung von Kopien oder das Weiterleiten an weitere, nicht originaere und benannte Adressaten ist nicht vorgesehen und kann ungesetzlich sein. Die Meinungen in dieser Nachricht stellen lediglich die Meinungen des Senders dar. Falls Sie vermuten, dass diese Nachricht veraendert wurde, setzen Sie sich mit dem Absender in Verbindung. Der Absender uebernimmt ohne weitere Ueberpruefung keine Verantwortung fuer die Richtigkeit und Vollstaendigkeit des Inhalts. Unbefugte Empfaenger werden gebeten, die Vertraulichkeit der Nachricht zu wahren und den Absender sofort ueber einen Uebertragungsfehler zu informieren. ------------------------------------------------------
I was also having the same problem. The latest snapshot of cygwin1.dll (9/20/05) solved it. HTH.
I run postgresql 7.4 on cygwin. After my database refused to start (after a crash), I executed pg_resetxlog and tried to restart the database: /usr/local/pgsql/bin/postmaster -d 5 -D /usr/local/pgsql/place After I issued this command, the database has been trying to recover itself, which is nice. The problem is that it has been recovering for almost 10 hours now, and it is still trying to go through all the PIDs. Can anybody tell me: is there a log file that tells me how many more PIDs need to be processed? I am just concerned how long this is going to take. I have a full back up of the data. The runtime log is something like: DEBUG: reaping dead processes DEBUG: child process (PID 5504) exited with exit code 0 DEBUG: proc_exit(0) DEBUG: shmem_exit(0) DEBUG: exit(0) DEBUG: reaping dead processes DEBUG: child process (PID 4652) exited with exit code 0 DEBUG: proc_exit(0) DEBUG: shmem_exit(0) DEBUG: exit(0) DEBUG: reaping dead processes DEBUG: child process (PID 6044) exited with exit code 0 Thanks, Changqing Zhou University of Minnesota