> Yeah, min_send_delay and max_slots_wal_keep_size should be easily tunable > because > the appropriate value depends on the enviroment and workload. > However, pg_replication_slots.pg_replication_slots cannot show the exact amout > of WALs, > so it may not suitable for tuning. I think user can compare the value > pg_replication_slots.restart_lsn (or pg_stat_replication.sent_lsn) and > pg_current_wal_lsn() to calclate number of WALs to be delayed, like > > ``` > postgres=# select pg_current_wal_lsn() - pg_replication_slots.restart_lsn as > delayed from pg_replication_slots; > delayed > ------------ > 1689153760 > (1 row) > ``` > > > I think it would be better to tell about this in the docs along with > > the 'min_send_delay' description. The key point is whether this would > > be an acceptable trade-off for users who want to use this feature. I > > think it can harm only if users use this without understanding the > > corresponding trade-off. As we kept the default to no delay, it is > > expected from users using this have an understanding of the trade-off. > > Yes, the trade-off should be emphasized.
Based on the understanding, I added them to the doc in new version patch. Please see [1]. [1]: https://www.postgresql.org/message-id/flat/TYAPR01MB586606CF3B585B6F8BE13A9CF5B29%40TYAPR01MB5866.jpnprd01.prod.outlook.com Best Regards, Hayato Kuroda FUJITSU LIMITED
