Re: [HACKERS] Allow interrupts on waiting standby - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [HACKERS] Allow interrupts on waiting standby
Date
Msg-id CAB7nPqTFXN8Q_NmjKEOZO6TUJYH=gain0XdZ9bzRAjA6mpRTrg@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Allow interrupts on waiting standby  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-hackers
On Fri, Jan 27, 2017 at 9:23 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On 27 January 2017 at 01:35, Michael Paquier <michael.paquier@gmail.com> wrote:
>> On Fri, Jan 27, 2017 at 4:36 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>>> On 26 January 2017 at 19:20, Andres Freund <andres@anarazel.de> wrote:
>> A deeper fix for HEAD proves to not be that complicated. Please see
>> the attached. The other two calls of pg_usleep() in standby.c are
>> waiting with 5ms and 10ms, it is not worth switching them to a latch.
>
> So you think 2 calls to pg_usleep() can stay; my opinion is 3 can stay.

This patch replaces one call of pg_usleep() where the wait can go up
to 1s, this is largely noticeable by the user. The two others sleep
for a maximum of 10ms. Even if a latch is used the code path is going
to exit immediately anyway. That's why you added a call to
CHECK_FOR_INTERRUPTS only here, no?

> I'm not clear why this particular call is worthy, while dozens of
> calls in other modules remain unchanged. This seems like a code issue
> rather than anything to do with Hot Standby in particular, so it
> should be another thread.

Some should switch to Latch.

> Doesn't seem important compared to other
> things for this release I should work on.

That's your call.

> Please add to the next CF so it gets proper review.

Sure.
-- 
Michael



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [HACKERS] Speedup twophase transactions
Next
From: Alvaro Herrera
Date:
Subject: Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superusercheck