| From: | Gyan Sreejith <gyan(dot)sreejith(at)gmail(dot)com> |
|---|---|
| To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
| Cc: | Euler Taveira <euler(at)eulerto(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, "kuroda(dot)hayato(at)fujitsu(dot)com" <kuroda(dot)hayato(at)fujitsu(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Peter Smith <smithpb2250(at)gmail(dot)com> |
| Subject: | Re: [Proposal] Adding Log File Capability to pg_createsubscriber |
| Date: | 2025-12-23 23:22:11 |
| Message-ID: | CAEqnbaVVp_g1m1nhOBZjtiAz5W-xwPQCmWH4hjYYehA+ktYg9Q@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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 1:49 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> On Thu, Dec 18, 2025 at 6:59 AM Euler Taveira <euler(at)eulerto(dot)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.
>
| Attachment | Content-Type | Size |
|---|---|---|
| 0001-Add-a-new-argument-l-logdir-to-pg_createsubscriber.patch | application/octet-stream | 9.5 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Chao Li | 2025-12-23 23:40:19 | Re: DOCS - "\d mytable" also shows any publications that publish mytable |
| Previous Message | Sami Imseih | 2025-12-23 23:07:29 | pg_stat_statements: Fix nested tracking for implicitly closed cursors |