Re: removing set_latch_on_sigusr1

From: Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: removing set_latch_on_sigusr1
Date: 2015-10-09 00:02:32
Message-ID: CAJrrPGfXYz8NOcBaLEwsvvq8A4kowX=UkmzSMrcioZ6JtdWufw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2015-10-09 00:20:00 Re: More work on SortSupport for text - strcoll() and strxfrm() caching
Previous Message Michael Paquier 2015-10-08 23:25:54 Re: Re: In-core regression tests for replication, cascading, archiving, PITR, etc.