> The previous postmaster coding blocked signals > everywhere except immediately around the main loop's select() call, > so there wasn't any real hazard of signal handlers interrupting > anything of concern. We redid it for cleanliness, not because there > was any observable bug.
Agreed, signal handlers are very sensitive (at least as of this moment) and the current approach looks very clean and safe.
> No, it was not.
> (If there had been a bug there, ProcessConfigFile would have been > the least of our problems, because all the other postmaster signals > were handled in the same style.)
Just as an info for future readers, it is indeed a bug for two reasons 1. changin GUC values in the signal handler, compiler might optimise the values so main control wouldn't have know about it later (90% sure about this) 2. ProcessConfigFile calls AllocSetCreate which in turn calls malloc which is not async signal safe(see man 7 signal-safety) and can cause deadlock in certain situations. (Dig malloc internal code if interested)
Not only in SIGHUP handler it is done in other handlers as well. Feel free to correct me if there is any inaccuracy in what I said.
