| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: WAL insert delay settings |
| Date: | 2019-02-14 08:52:17 |
| Message-ID: | CAH2-Wz=A_8p7K4KuZpHrAvk4-nyOdWHpSEjw+tjCtuWAZay-VA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Feb 14, 2019 at 12:42 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
> That can't have been the workaround - either you'd interrupt it while
> holding critical locks (in which case nobody could write WAL anymore),
> or you'd just move all the writing to backends, no?
I imagine that it held the critical locks briefly. I'm not endorsing
that approach, obviously, but apparently it more or less worked. It
was something that was used in rare cases, only when there was no
application-specific way to throttle writes, and only when the server
was in effect destabilized by writing out WAL too quickly.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2019-02-14 08:53:54 | Re: WAL insert delay settings |
| Previous Message | Andres Freund | 2019-02-14 08:42:18 | Re: WAL insert delay settings |