On Fri, Sep 21, 2018 at 12:35:46PM +0200, Chris Travers wrote: > I understand how lock levels don't fit a simple hierarchy but at least > when it comes to what is going to be aborted on a signal, I am having > trouble understanding the problem here.
It may be possible to come with a clear hierarchy with the current interruption types in place. Still I am not sure that the definition you put behind is completely correct, and I think that we need to question as well the value of putting such restrictions for future interruption types because they would need to fit into it. That's quite a heavy constraint to live with. There is such logic with wal_level for example, which is something I am not completely happy with either... But this one is a story for another time, and another thread. Regarding your patch, it seems to me that it does not improve readability as I mentioned up-thread because you lose sight of what can be interrupted in a given code path, which is what the current code shows actually nicely. There could be value in refactoring things so as all the *Pending flags of miscadmin.h get stored into one single volatile sig_atomic_t which uses bit-wise markers, as that's at least 4 bytes because that's stored as an int for most platforms and can be performed as an atomic operation safely across signals (If my memory is right;) ). And this leaves a lot of room for future flags. -- Michael
signature.asc
Description: PGP signature
