Thank you for the feedback everybody. As I read through this email chain, I found differing opinions on how logging should be implemented. This ambiguity leaves me unsure as to which solution(s) to pursue. As of right now, I have attached the git-format patch like Hayato Kuroda recommended (but it does not have any new changes). I am willing to implement whatever solution when we reach a consensus.
Thank you for all of the help,
Gyan Sreejith
On Thu, Dec 18, 2025 at 6:59 AM Euler Taveira <euler@eulerto.com> 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.
