Jeff Janes wrote > > Maybe there is an easier way, but one thing would be to compile a test > server (of the same version as the production) with WAL_DEBUG defined > in src/include/pg_config_manual.h, turn on the wal_debug guc, and > crank up trace_recovery_messages. Then replay the WAL log files from > production through this test server and see what it logs. That > requires that you have > > Easier would to be turn on wal_debug and watch the server log as the > WAL logs are generated, instead of recovered, but you probably don't > want to do that on production. So you would need a workload generator > that also exhibits the phenomenon of interest. > This sounds like it may help me see what is going on. However I am not finding very much documentation as to how to do this exactly. What I have is it seems this has to be set and postgres needs to be re-compiled to enable it. Is this true? As that would not really be a viable option right now. I am in position to set up a test server and run wal files through it. But I am not sure how to accomplish this exactly? Is there somewhere you anyone could point me to find documentation on how to do this? Thanks a lot for everyone's input so far. -- View this message in context: http://postgresql.1045698.n5.nabble.com/Increasing-WAL-usage-followed-by-sudden-drop-tp5719567p5720492.html Sent from the PostgreSQL - performance mailing list archive at Nabble.com. -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
