MIME-Version: 1.0
References: 
 <CAEqnbaUthOQARV1dscGvB_EsqC-YfxiM6rWkVDHc+G+f4oSUHw@mail.gmail.com>
 <CAHut+PvizcpeHA1Twf_hwe=wANQ1LV5zY6_q+39gTFJc7+bCKg@mail.gmail.com>
 <CAEqnbaVNZYbB_YufchM49d=XC1ZGrVV8ikCPmGotWoCZASY3Uw@mail.gmail.com>
 <CAEqnbaV8QMbXZtt25QtGUPAaQZnD-B0HniFSroapMh+QTZgKsQ@mail.gmail.com>
 <OSCPR01MB14966FD0961F512B29BD46D6BF5AAA@OSCPR01MB14966.jpnprd01.prod.outlook.com>
 <CALDaNm0gX2D6fD5yur-R5gagA7+AfLmLZU5Z8+tgjo61b-Y01w@mail.gmail.com>
 <48261e54-c4f1-4bde-a4a9-4f3698a6b380@app.fastmail.com>
In-Reply-To: <48261e54-c4f1-4bde-a4a9-4f3698a6b380@app.fastmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
Date: Thu, 18 Dec 2025 12:19:02 +0530
Message-ID: 
 <CAA4eK1+2PYU-y2weY_zFeysP8Ux45iBNdaYMZuJtMTqXwCxawQ@mail.gmail.com>
Subject: Re: [Proposal] Adding Log File Capability to pg_createsubscriber
To: Euler Taveira <euler@eulerto.com>
Cc: vignesh C <vignesh21@gmail.com>,
	"kuroda.hayato@fujitsu.com" <kuroda.hayato@fujitsu.com>,
 Gyan Sreejith <gyan.sreejith@gmail.com>,
	"pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>,
 Peter Smith <smithpb2250@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAA4eK1%2B2PYU-y2weY_zFeysP8Ux45iBNdaYMZuJtMTqXwCxawQ%40mail.gmail.com>
Precedence: bulk

On Thu, Dec 18, 2025 at 6:59=E2=80=AFAM Euler Taveira <euler@eulerto.com> w=
rote:
>
> 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 fi=
le? I
> doubt it. There is already various ways to capture. psql and pg_upgrade a=
re 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

--=20
With Regards,
Amit Kapila.