From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: WAL insert delay settings |
Date: | 2019-02-14 07:21:39 |
Message-ID: | CAH2-Wzkzop9kyO5F82-O=HnBn3qJCaGSLMDoGhvTHGJKub-cvg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Feb 13, 2019 at 4:16 AM Peter Eisentraut
<peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
> Bulk operations like CREATE INDEX, ALTER TABLE, or bulk loads can create
> a lot of WAL. A lot of WAL at once can cause delays in replication.
> For synchronous replication, this can make seemingly unrelated sessions
> hang. But also for asynchronous replication, it will increase latency.
I think that I suggested a feature like this early during my time at
Heroku, about 5 years ago. There would occasionally be cases where ops
would find it useful to throttle WAL writing using their own terrible
kludge (it involved sending SIGSTOP to the WAL writer).
I recall that this idea was not well received at the time. I still
think it's a good idea, though. Provided there is a safe way to get it
to work.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Tsunakawa, Takayuki | 2019-02-14 07:23:18 | RE: Protect syscache from bloating with negative cache entries |
Previous Message | Michael Paquier | 2019-02-14 07:13:13 | Re: Incorrect visibility test function assigned to snapshot |