On Wed, Dec 8, 2021 at 12:52 PM Michael Paquier <mich...@paquier.xyz> wrote: > > On Wed, Dec 08, 2021 at 10:47:57AM +0530, Bharath Rupireddy wrote: > > Thanks for taking a look at the patch. How about the attached v4? > > > > I added a CF entry - https://commitfest.postgresql.org/36/3443/ > > + else if (source == XLOG_FROM_STREAM) > + ereport(LOG, > + (errmsg("recovering WAL segment \"%s\" received from > primary", > + xlogfname))); > This is incorrect when using a cascading standby.
I visualize the setup like this: primary -> standby -> cascading standby For standby, "received from primary" makes sense. For cascading standby too it makes sense because the standby still acts as primary for cascading standby, no? And we don't distinguish any other existing messages for a standby acting as a cascading standby right? The comments around the enum XLOG_FROM_STREAM and usage of it still says from "primary". Do you want me to add "received from stream" in general? > And perhaps this could use a switch/case? Yes, I will change it to switch-case in the next version. > While quickly testing, I got reminded that the LOG for a segment > retrieved from the local pg_wal would generate some noise when running > for example the bootstrap process. Is this one really interesting > compared to the two others? Yes. I observed that for a simple primary-standby setup, inserting 10million rows generated around 40 WAL files and so 40 LOG messages in the standby server logs, in a typical production environment with heavy-write workload, the amount of LOG generation is going to be much more. And we don't want to have them as DEBUG1 messages and enable DEBUG1 just for recovery messages that one is interested in. How about we invent a new GUC log_recovery, with default set to false, similar to log_checkpoints? And, these messages can be like: ereport(log_recovery ? LOG : DEBUG1, .....)? This GUC can be useful to add some recovery stats in future as well. Thoughts? Regards, Bharath Rupireddy.
