Re: [HACKERS] pg_basebackup throttling doesn't throttle as promised - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [HACKERS] pg_basebackup throttling doesn't throttle as promised
Date
Msg-id CAB7nPqQD6EOxq=dEJ78RVveqjEwO36aGkSPQaUYPGMJcn5ZBpA@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] pg_basebackup throttling doesn't throttle as promised  (Jeff Janes <jeff.janes@gmail.com>)
List pgsql-hackers
On Sat, Sep 2, 2017 at 6:42 AM, Jeff Janes <jeff.janes@gmail.com> wrote:
> I'm attaching a patch for each option.  Each one independently solves the
> problem.  But I think we should do both.  There is no point in issuing
> unnecessary kill system calls, and there may also be more spurious wake-ups
> than just these ones.

I agree that 1) and 2) are sensible things to do now. At some point I
think that we will want do_pg_stop_backup() to use a wait event
instead of a pg_usleep call when waiting for a segment to be archived,
in which case we could use WalSndWakeup() to set the latch and
accelerate things. So it would be nice to keep track of this
possibility in the code. We could as well do that with a new API only
signalling WAL senders in backup state though.
               SpinLockAcquire(&walsnd->mutex);               latch = walsnd->latch;
+               state = walsnd->state;               SpinLockRelease(&walsnd->mutex);

-               if (latch != NULL)
+               if (latch != NULL && state != WALSNDSTATE_BACKUP)                       SetLatch(latch);
This surely meritates a comment.
-- 
Michael



pgsql-hackers by date:

Previous
From: Amit Khandekar
Date:
Subject: Re: [HACKERS] UPDATE of partition key
Next
From: Dilip Kumar
Date:
Subject: Re: [HACKERS] Proposal: Improve bitmap costing for lossy pages