Hi,
On 2020-06-09 17:04:42 -0400, Robert Haas wrote:
> On Tue, Jun 9, 2020 at 3:37 PM Andres Freund <andres@anarazel.de> wrote:
> > Hm. Looking at this again, perhaps the better fix would be to simply not
> > look at the concrete values of the barrier inside the signal handler?
> > E.g. we could have a new PROCSIG_GLOBAL_BARRIER, which just triggers
> > ProcSignalBarrierPending to be set. And then have
> > ProcessProcSignalBarrier do the check that's currently in
> > CheckProcSignalBarrier()?
>
> That seems like a good idea.
Cool.
> Also, I wonder if someone would be willing to set up a BF animal for this.
You mean having both --disable-atomics and --disable-spinlocks? If so,
I'm planning to do that (I already have the animals that do those
separately, so it seems to make sense to add it to that collection).
What do you think about my idea of having a BEGIN/END_SIGNAL_HANDLER?
That'd make it much easier to write assertions forbidding palloc, 64bit
atomics, ...
Greetings,
Andres Freund
