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

From Jeff Janes
Subject Re: [HACKERS] pg_basebackup throttling doesn't throttle as promised
Date
Msg-id CAMkU=1wtMbDSGHcheo_xSHpFi=M2dLsFX6deqJNNoP33N=gvug@mail.gmail.com
Whole thread Raw
In response to [HACKERS] pg_basebackup throttling doesn't throttle as promised  (Jeff Janes <jeff.janes@gmail.com>)
Responses Re: [HACKERS] pg_basebackup throttling doesn't throttle as promised
Re: [HACKERS] pg_basebackup throttling doesn't throttle as promised
Re: [HACKERS] pg_basebackup throttling doesn't throttle as promised
List pgsql-hackers
On Fri, Sep 1, 2017 at 1:32 PM, Jeff Janes <jeff.janes@gmail.com> wrote:
The "-r" option to pg_basebackup is supposed to throttle the rate of the backup.  But it only works properly if the server is mostly idle.

Every non-trivial call to XLogFlush or XLogBackgroundFlush will wake up the wal sender (the one which is not really sending wal, but base files), and the throttling routine doesn't go back to sleep after being awoke early.  Rather, it releases another 32kb of data.


Should the basebackup.c throttle sleep in a loop until its time has expired?  

Or should walsender.c WalSndWakeup not wake a wal sender whose status is WALSNDSTATE_BACKUP?

Or both?


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.

Cheers,

Jeff
Attachment

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] tupconvert.c API change in v10 release notes
Next
From: Thomas Munro
Date:
Subject: Re: [HACKERS] Parallel Hash take II