Robert Haas <robertmh...@gmail.com> writes: > On Mon, Aug 1, 2016 at 7:42 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> ... This is what makes me dubious that getting rid >> of doing work in the postmaster's signal handlers is really going >> to add any noticeable increment of safety. It might make the >> code look cleaner, but I'm afraid it's going to be a lot of churn >> for not much gain.
> It's not just a cosmetic issue. > See > https://www.postgresql.org/message-id/CA+Tgmobr+Q2WgWeasdbDNefVwJkAGALxA=-vtegntqgl1v2...@mail.gmail.com > and d0410d66037c2f3f9bee45e0a2db9e47eeba2bb4. I do not think that patch particularly bears on this question. We have had logic bugs in the postmaster in the current coding structure, and we undoubtedly would still have logic bugs in the postmaster if it were rewritten to avoid using nontrivial signal handlers. They'd just be in different places. Also, the message you mention does a fine job of summarizing why getting out of the signal-handler-based design will be fraught with a bunch of new portability hazards. But what I was responding to here is the claim that we have portability hazards built into the current code as a consequence of doing work in the signal handlers. AFAICT, that's just FUD, and is sufficiently disproven by the many years of reliable service we've gotten out of the current design. Anyway, if someone is really motivated to rewrite the postmaster, I won't stand in the way. I'm just opining that that it will be a lot of work that would be better expended elsewhere. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
