| From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Greg Stark <gsstark(at)mit(dot)edu>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: SR standby hangs |
| Date: | 2011-04-26 21:05:03 |
| Message-ID: | 4DB7337F.9080803@dunslane.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 04/26/2011 04:45 PM, Tom Lane wrote:
> I wrote:
>> Well, that's pretty interesting: refcount is only 1, and the
>> BM_PIN_COUNT_WAITER flag is not set. AFAICS this *must* mean that the
>> buffer had been pinned and whoever had it (presumably bgwriter) did
>> UnpinBuffer(). So it appears that the signal just plain got lost :-(,
>> which suggests a kernel bug. What platform is this on, again?
> BTW, could you confirm that the startup process's PID is 9111 as the
> bufhdr suggests?
postgres 9111 9105 0 Apr02 ? 00:37:38 postgres: startup
process recovering 000000040000036D00000033
> Also, it'd be good to confirm that
> procglobal->startupProcPid and procglobal->startupProc point to the
> startup process. I notice that ProcSendSignal will silently do nothing
> if it doesn't find the target process's PGPROC, which might have
> something to do with this ...
Not sure if I'm looking in the right spot, but this looks suspicious:
(gdb) p 'postmaster.c'::ProcGlobal->startupProcPid
$1 = 0
(gdb) p 'postmaster.c'::ProcGlobal->startupProc
$2 = (PGPROC *) 0x0
cheers
andrew
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kevin Grittner | 2011-04-26 21:09:25 | Re: Proposal - asynchronous functions |
| Previous Message | Tom Lane | 2011-04-26 20:45:34 | Re: SR standby hangs |