Re: Syncrep and improving latency due to WAL throttling
От | Bharath Rupireddy |
---|---|
Тема | Re: Syncrep and improving latency due to WAL throttling |
Дата | |
Msg-id | CALj2ACW339Dk-E31S_x6hX4SdEHkH8LOY9afvwQXORJjVk8xQQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Syncrep and improving latency due to WAL throttling (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
Ответы |
Re: Syncrep and improving latency due to WAL throttling
|
Список | pgsql-hackers |
On Fri, Jan 27, 2023 at 2:03 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote: > > On 2023-Jan-27, Bharath Rupireddy wrote: > > > Looking at the patch, the feature, in its current shape, focuses on > > improving replication lag (by throttling WAL on the primary) only when > > synchronous replication is enabled. Why is that? Why can't we design > > it for replication in general (async, sync, and logical replication)? > > > > Keeping replication lag under check enables one to provide a better > > RPO guarantee > > Hmm, but you can already do that by tuning walwriter, no? IIUC, one can increase wal_writer_delay or wal_writer_flush_after to control the amount of WAL walwriter writes and flushes so that the walsenders will get slower a bit thus improving replication lag. If my understanding is correct, what if other backends doing WAL writes and flushes? How do we control that? I think tuning walwriter alone may not help to keep replication lag under check. Even if it does, it requires manual intervention. -- Bharath Rupireddy PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
В списке pgsql-hackers по дате отправления: