From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Magnus Hagander <magnus(at)hagander(dot)net>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Daniel Gustafsson <daniel(at)yesql(dot)se> |
Subject: | Re: global / super barriers (for checksums) |
Date: | 2019-11-25 22:44:21 |
Message-ID: | CA+TgmoaY9Uf2h-PHh8tFLR=FJMO7A4RLwao-m6ye965dQoNuPA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Nov 13, 2019 at 12:26 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On the other hand, 0002 seems like it's pretty clearly a good idea. It
> makes a whole bunch of auxiliary processes use
> procsignal_sigusr1_handler() and those things all get called from
> AuxiliaryProcessMain(), which does ProcSignalInit(), and it seems like
> clearly the right idea that processes which register to participate in
> the procsignal mechanism should also register to get notified if they
> receive a procsignal. I think that the reason we haven't bothered with
> this up until now is because I think that it's presently impossible
> for any of the kind of procsignals that we have to get sent to any of
> those processes. But, global barriers would require us to do so, so it
> seems like it's time to tighten that up, and it doesn't really cost
> anything. So I propose to commit this part soon, unless somebody
> objects.
Done.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2019-11-25 22:51:41 | Re: benchmarking Flex practices |
Previous Message | Andrew Dunstan | 2019-11-25 21:56:24 | Re: Allow superuser to grant passwordless connection rights on postgres_fdw |