Re: "stuck spinlock"
От | Tom Lane |
---|---|
Тема | Re: "stuck spinlock" |
Дата | |
Msg-id | 22510.1386952004@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: "stuck spinlock" (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: "stuck spinlock"
Re: "stuck spinlock" |
Список | pgsql-hackers |
On closer inspection, I'm thinking that actually it'd be a good idea if handle_sig_alarm did what we do in, for example, HandleCatchupInterrupt: it should save, clear, and restore ImmediateInterruptOK, so as to make the world safe for timeout handlers to do things that might include a CHECK_FOR_INTERRUPTS. And while we're on the subject ... isn't bgworker_die() utterly and completely broken? That unconditional elog(FATAL) means that no process using that handler can do anything remotely interesting, like say touch shared memory. I didn't find any other similar hazards in a quick look through all our signal handlers. regards, tom lane
В списке pgsql-hackers по дате отправления: