| From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Dave Page <dave(dot)page(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, CM Team <cm(at)enterprisedb(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, bernd(dot)helmle(at)credativ(dot)de |
| Subject: | Re: test_shm_mq failing on anole (was: Sending out a request for more buildfarm animals?) |
| Date: | 2014-09-29 21:49:40 |
| Message-ID: | 20140929214940.GH2084@awork2.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2014-09-29 18:44:34 -0300, Alvaro Herrera wrote:
> Andres Freund wrote:
>
> > I'm generally baffled at all the stuff postmaster does in signal
> > handlers... ProcessConfigFile(), load_hba() et al. It's all done with
> > signals disabled, but still.
>
> As far as I recall, the rationale for why this is acceptable is that the
> whole of postmaster is run with signals blocked; they are only unblocked
> during the sleeping select().
Yea, I wrote that above :). Still seems remarkably fragile and
unnecessarily complex. The whole thing would be much simpler and
importantly easier to understand if everything would be done inside the
mainloop and the handlers just would set a latch...
But I guess that'd be a bit of large change to something as central as
postmaster's code..
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Josh Berkus | 2014-09-29 21:54:31 | Re: Yet another abort-early plan disaster on 9.3 |
| Previous Message | Alvaro Herrera | 2014-09-29 21:44:34 | Re: test_shm_mq failing on anole (was: Sending out a request for more buildfarm animals?) |