| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
| 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 20:45:34 |
| Message-ID: | 21744.1303850734@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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? 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 ...
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2011-04-26 21:05:03 | Re: SR standby hangs |
| Previous Message | Greg Smith | 2011-04-26 20:44:31 | Re: Improving the memory allocator |