On Thu, Dec 18, 2025 at 6:59 AM Euler Taveira <[email protected]> wrote: > > On Wed, Dec 17, 2025, at 7:07 AM, vignesh C wrote: > > > > By providing this as an option, users can store the log files outside > > the data directory, eliminating the need for any additional handling > > during backups. > > > > Do we really need an option to capture the stdout / stderr output to a file? I > doubt it. There is already various ways to capture. psql and pg_upgrade are > the > only tools that have this option. >
pg_ctl also has the -l option. I think any place where long text/errors can be outputted, a log file is preferred because one could later parse it to know the exact details. Also, splitting the log as proposed here or in pg_upgrade helps to navigate the LOG like is the problem in start/stop of the server or a pub-sub setup? Similarly the log can be splitted for pub/sub specific information. There appears to be some useful information like: pg_createsubscriber: warning: two_phase option will not be enabled for replication slots pg_createsubscriber: detail: Subscriptions will be created with the two_phase option disabled. Prepared transactions will be replicated at COMMIT PREPARED. pg_createsubscriber: hint: You can use the command-line option --enable-two-phase to enable two_phase. I think it will be useful to LOG this separately from the main LOG [1] (which can contain server specific info as follows) so that users can consider running pg_createsubscriber with additional options or changing the subscriber configuration once setup is complete. [1]: [startup] LOG: database system was interrupted; last known up at 2025-12-17 14:46:07 IST [startup] LOG: starting backup recovery with redo LSN 0/06000028, checkpoint LSN 0/06000080, on timeline ID 1 [startup] LOG: entering standby mode [startup] LOG: redo starts at 0/06000028 [startup] LOG: completed backup recovery with redo LSN 0/06000028 and end LSN 0/06000120 [startup] LOG: consistent recovery state reached at 0/06000120 -- With Regards, Amit Kapila.
