Re: pg_basebackup throttling doesn't throttle as promised

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_basebackup throttling doesn't throttle as promised
Date: 2017-09-04 05:26:37
Message-ID: CAB7nPqQD6EOxq=dEJ78RVveqjEwO36aGkSPQaUYPGMJcn5ZBpA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Sep 2, 2017 at 6:42 AM, Jeff Janes <jeff(dot)janes(at)gmail(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dilip Kumar 2017-09-04 05:48:17 Re: Proposal: Improve bitmap costing for lossy pages
Previous Message Amit Khandekar 2017-09-04 05:22:16 Re: UPDATE of partition key