| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
| Cc: | Jakub Wartak <jakub(dot)wartak(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
| Subject: | Re: Syncrep and improving latency due to WAL throttling |
| Date: | 2023-01-26 15:51:24 |
| Message-ID: | 20230126155124.xnifvlnbpnah32qf@awork3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2023-01-26 13:33:27 +0530, Bharath Rupireddy wrote:
> 6. Backends can ignore throttling for WAL records marked as unimportant, no?
Why would that be a good idea? Not that it matters today, but those records
still need to be flushed in case of a commit by another transaction.
> 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?
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jelte Fennema | 2023-01-26 16:16:52 | Re: run pgindent on a regular basis / scripted manner |
| Previous Message | Andres Freund | 2023-01-26 15:49:12 | Re: Syncrep and improving latency due to WAL throttling |