| From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
| Cc: | Antonin Houska <antonin(dot)houska(at)gmail(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Backup throttling |
| Date: | 2014-01-16 20:03:29 |
| Message-ID: | 20140116200329.GE30206@awork2.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2014-01-15 18:52:32 -0300, Alvaro Herrera wrote:
> Another thing I found a bit strange was the use of the latch. What this
> patch does is create a separate latch which is used for the throttling.
> This means that if the walsender process receives a signal, it will not
> wake up if it's sleeping in throttling. Perhaps this is okay: as Andres
> was quoted upthread as saying, maybe this is not a problem because the
> sleep times are typically short anyway. But we're pretty much used to
> the idea that whenever a signal is sent, processes act on it
> *immediately*. Maybe some admin will not feel comfortable about waiting
> some extra 20ms when they cancel their base backups. In any case,
> having a secondary latch to sleep on in a process seems weird. Maybe
> this should be using MyWalSnd->latch somehow.
Yes, this definitely should reuse MyWalSnd->latch.
slightly related: we should start to reuse procLatch for walsenders
instead of having a separate latch someday.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2014-01-16 20:32:05 | Re: Display oprcode and its volatility in \do+ |
| Previous Message | Alvaro Herrera | 2014-01-16 19:54:19 | Re: Review: ECPG infrastructure changes part 1, was: Re: ECPG fixes |