On Thu, Dec 9, 2021 at 9:28 PM Alvaro Herrera <alvhe...@alvh.no-ip.org> wrote: > > On 2021-Dec-09, Bharath Rupireddy wrote: > > > On Thu, Dec 9, 2021 at 6:00 PM Alvaro Herrera <alvhe...@alvh.no-ip.org> > > wrote: > > > > > > On 2021-Dec-09, Bharath Rupireddy wrote: > > > > > > > I just want to call this out: an insertion of 10 million rows in the > > > > primary generates a bunch of messages in the standby [1] within 40 sec > > > > (size of the standby server log grows by 5K). > > > > > > Hmm, that does sound excessive to me in terms of log bloat increase. > > > Remember the discussion about turning log_checkpoints on by default? > > > > The amount of LOG messages generated when the log_checkpoints GUC is > > set to on, are quite less, hardly 4 messages per-checkpoint (5min). I > > think enabling log_checkpoints is still acceptable as most of the > > hackers agreed in another thread [1] that the advantages with it are > > more and it doesn't seem to be bloating the server logs (in a day at > > max 1152 messages). > > My point is that it was argued, in that thread, that setting > log_checkpoints to on by default would cause too much additional log > volume. That argument was shot down, but in this thread we're arguing > that we want five kilobytes of messages in forty seconds. That sounds > much less acceptable to me, so making it default behavior or > unconditional behavior is not going to fly very high. > > > I'm not sure if it is worth having a GUC log_recovery if enabled the > > recovery messages can be emitted at LOG level otherwise DEBUG1 level. > > Maybe some tunable like > log_wal_traffic = { none, medium, high } > where "none" is current behavior of no noise, "medium" gets (say) once > every 256 segments (e.g., when going from XFF to (X+1)00), "high" gets > you one message per segment.
Yeah, that can be an option. Another idea could be to use the infrastructure laid out by the commit 9ce346e [1]. With ereport_startup_progress, we can emit the LOGs(of current recovering WAL file) for every log_startup_progress_interval seconds/milliseconds. One problem is that ereport_startup_progress doesn't work on StandbyMode, maybe we can remove this restriction unless we have a major reason for not allowing it on the standby. /* Prepare to report progress of the redo phase. */ if (!StandbyMode) begin_startup_progress_phase(); Thoughts? [1] commit 9ce346eabf350a130bba46be3f8c50ba28506969 Author: Robert Haas <rh...@postgresql.org> Date: Mon Oct 25 11:51:57 2021 -0400 Report progress of startup operations that take a long time. Discussion: https://postgr.es/m/ca+tgmoahqrgdfobwgy16xcomtxxsrvgfb2jncvb7-ubuee1...@mail.gmail.com Discussion: https://postgr.es/m/camm1awahf7ve69572_olq+mgpt5ruiudgf1x5rrtkjbldpr...@mail.gmail.com Regards, Bharath Rupireddy.