| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Kevin Izzet" <Kevin(dot)Izzet(at)nsc(dot)com> |
| Cc: | pgsql-admin(at)postgresql(dot)org |
| Subject: | Re: psql won't stayed connected |
| Date: | 2004-08-05 19:13:06 |
| Message-ID: | 20260.1091733186@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
"Kevin Izzet" <Kevin(dot)Izzet(at)nsc(dot)com> writes:
> Aug 5 17:01:38 uklnx04 postgres[28522]: [230-1] DEBUG: 00000:
> InitPostgres
> Aug 5 17:01:38 uklnx04 postgres[28522]: [230-2] LOCATION: PostgresMain,
> postgres.c:2639
> Aug 5 17:01:38 uklnx04 postgres[28522]: [231-1] DEBUG: 00000:
> proc_exit(0)
> Aug 5 17:01:38 uklnx04 postgres[28522]: [231-2] LOCATION: proc_exit,
> ipc.c:95
That's pretty bizarre ... I didn't think there were any code paths that
would get to proc_exit without emitting an error message.
Can you set a debugger breakpoint at proc_exit and see what the call
stack looks like? (You can slow things down enough to attach to the
backend with gdb by using the -W switch:
PGOPTIONS="-W 30" psql ...
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Senthil Jegadeesan | 2004-08-06 04:25:07 | Connecting to remote Database |
| Previous Message | Kevin Izzet | 2004-08-05 16:05:32 | psql won't stayed connected |