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
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. |