On Fri, Oct 9, 2015 at 2:41 AM, Robert Haas <robertmh...@gmail.com> wrote: > > As it happens, the TupleQueueFunnelNext function I recently committed > has such a hazard, which I failed to spot during review and testing. > If people don't like this, I can instead cause that function to set > the flag. But every place that sets the flag has to use a > PG_TRY()/PG_CATCH() block to make sure the old value of the flag gets > restored. I'm pretty sure that's going to burn more cycles than the > flag can ever hope to save, not to mention the risk of bugs due to > people forgetting to add necessary volatile qualifiers. We've already > got four PG_TRY() blocks in the code to cater to this stupid flag, and > if we keep it around I'm sure we'll accumulate at least a few more. > > Patch attached. Objections? Suggestions? Comments?
Once I also faced a problem with set_latch_on_sigusr1 flag in our development. +1 for removal. Regards, Hari Babu Fujitsu Australia -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers