On Fri, Oct 9, 2015 at 2:41 AM, Robert Haas <robertmhaas@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
