Re: Syncrep and improving latency due to WAL throttling
От | Bharath Rupireddy |
---|---|
Тема | Re: Syncrep and improving latency due to WAL throttling |
Дата | |
Msg-id | CALj2ACWttN5DA9urjKgyapRxX6pYtw_okJ0nA3VfLZekpy7VNA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Syncrep and improving latency due to WAL throttling (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Syncrep and improving latency due to WAL throttling
Re: Syncrep and improving latency due to WAL throttling Re: Syncrep and improving latency due to WAL throttling |
Список | pgsql-hackers |
On Thu, Jan 26, 2023 at 9:21 PM Andres Freund <andres@anarazel.de> wrote: > > > 7. I think we need to not let backends throttle too frequently even > > though they have crossed wal_throttle_threshold bytes. The best way is > > to rely on replication lag, after all the goal of this feature is to > > keep replication lag under check - say, throttle only when > > wal_distance > wal_throttle_threshold && replication_lag > > > wal_throttle_replication_lag_threshold. > > I think my idea of only forcing to flush/wait an LSN some distance in the past > would automatically achieve that? I'm sorry, I couldn't get your point, can you please explain it a bit more? 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 as discussed in the other thread https://www.postgresql.org/message-id/CAHg%2BQDcO_zhgBCMn5SosvhuuCoJ1vKmLjnVuqUEOd4S73B1urw%40mail.gmail.com. -- Bharath Rupireddy PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
В списке pgsql-hackers по дате отправления: