BUG #3858: psql hangs if called as postgres is coming online
The following bug has been logged online:
Bug reference: 3858
Logged by: Faisal N. Jawdat
Email address: faisal@faisal.com
PostgreSQL version: 8.2.5
Operating system: Mac OS X
Description: psql hangs if called as postgres is coming online
Details:
If I use psql on a local database while the daemon is coming online, psql
hangs and most be killed. Subsequent psql processes will connect without
incident.
This is relevant for Mac OS X in particular because the bug prevents
PostgreSQL from being used with launchd as an on-demand service -- running
psql will cause postgres to launch, but the first psql process will be hung.
This behavior does not impact running PostgreSQL at startup (or manually)
under launchd.
Please mail me if you need launchd plists for these configurations.
Faisal N. Jawdat wrote:
If I use psql on a local database while the daemon is coming online, psql
hangs and most be killed. Subsequent psql processes will connect without
incident.
This is strange. When the postmaster is not ready to receive
connections, psql is supposed to die with an error message stating so.
It should not hang under no circumstances.
Can you get a backtrace of the hung psql process?
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
(gdb) backtrace
#0 0x91542152 in poll$UNIX2003 ()
#1 0x0004867a in pqSocketCheck ()
#2 0x00048a41 in pqWaitTimed ()
#3 0x00042cbc in connectDBComplete ()
#4 0x00044b02 in PQsetdbLogin ()
#5 0x0000d30f in main ()
-faisal
On Jan 8, 2008, at 6:34 PM, Alvaro Herrera wrote:
Show quoted text
Faisal N. Jawdat wrote:
If I use psql on a local database while the daemon is coming
online, psql
hangs and most be killed. Subsequent psql processes will connect
without
incident.This is strange. When the postmaster is not ready to receive
connections, psql is supposed to die with an error message stating so.
It should not hang under no circumstances.Can you get a backtrace of the hung psql process?
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Alvaro Herrera <alvherre@commandprompt.com> writes:
Can you get a backtrace of the hung psql process?
strace'ing it up to the point of the hang might be informative too.
regards, tom lane
Using a Mac, so no strace. dtruss of any use?
-faisal
On Jan 8, 2008, at 7:03 PM, Tom Lane wrote:
Show quoted text
Alvaro Herrera <alvherre@commandprompt.com> writes:
Can you get a backtrace of the hung psql process?
strace'ing it up to the point of the hang might be informative too.
regards, tom lane
Faisal N. Jawdat wrote:
Using a Mac, so no strace. dtruss of any use?
Sure.
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Alvaro Herrera <alvherre@commandprompt.com> writes:
Faisal N. Jawdat wrote:
Using a Mac, so no strace. dtruss of any use?
Sure.
Or ktrace, which seems standard on my Macs whereas I don't see dtruss.
Take your pick, we just want to see the sequence of kernel calls ...
regards, tom lane
ktrace apparently didn't make it to osx 10.5.1. hrm. let me dig
around.
-faisal
On Jan 8, 2008, at 9:13 PM, Tom Lane wrote:
Show quoted text
Alvaro Herrera <alvherre@commandprompt.com> writes:
Faisal N. Jawdat wrote:
Using a Mac, so no strace. dtruss of any use?
Sure.
Or ktrace, which seems standard on my Macs whereas I don't see dtruss.
Take your pick, we just want to see the sequence of kernel calls ...regards, tom lane
Faisal N. Jawdat wrote:
Using a Mac, so no strace. dtruss of any use?
Any luck with either dtruss or ktrace?
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
"Faisal N. Jawdat" <faisal@faisal.com> writes:
If I use psql on a local database while the daemon is coming online, psql
hangs and most be killed. Subsequent psql processes will connect without
incident.
FWIW, I just spent some time trying to duplicate this on OSX 10.4.11,
without success. I ran the postmaster under gdb and tried psql from
another window at interesting points during the startup sequence. psql
either fails instantly if started before the postmaster has executed
listen(), or waits till the postmaster responds with "FATAL: the
database system is starting up" if started during the subsequent startup
processing, or comes up fine if started later.
Perhaps you are looking at a kernel bug in 10.5?
regards, tom lane