| From: | Chapman Flack <chap(at)anastigmatix(dot)net> |
|---|---|
| To: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Signals in a BGW |
| Date: | 2017-12-04 16:40:37 |
| Message-ID: | a8080882-bac7-e539-05a9-eb6cd3d628d6@anastigmatix.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
I'm curious about handling signals in a background worker.
As I understand it, these are blocked when the BGW is born, until
enabled with BackgroundWorkerUnblockSignals() after possible
customization.
Is there a known, default behavior that some signals will
have, if I simply BackgroundWorkerUnblockSignals() without customizing?
Will SIGINT and SIGTERM, for example, have default handlers that
interact with the volatile flags in miscadmin.h that are used by
CHECK_FOR_INTERRUPTS, and set the process latch?
I notice that the worker_spi example code customizes SIGHUP
and SIGTERM, giving them handlers that set a (different, local
to the module) volatile flag, and set the process latch.
The example code does call CHECK_FOR_INTERRUPTS, though I assume
this won't detect ProcDie at all, now that the custom SIGTERM
handler is setting a different, local flag. Perhaps it still
does something useful with QueryCancel?
Does this use of a custom SIGTERM handler, setting a custom flag,
setting the process latch, and then checked in custom code,
accomplish something important that would not be accomplished
by a generic handler and CHECK_FOR_INTERRUPTS ?
I'm just not clearly grasping the reason it's customized here.
-Chap
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2017-12-04 16:44:37 | Re: [HACKERS] Secondary index access optimizations |
| Previous Message | Konstantin Knizhnik | 2017-12-04 16:14:57 | Re: [HACKERS] Secondary index access optimizations |