| From: | Sami Imseih <samimseih(at)gmail(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: rename pg_log_standby_snapshot |
| Date: | 2025-04-07 01:38:45 |
| Message-ID: | CAA5RZ0swNXYtUNXm8ndu6iGHs9dwXUGH0x4yjOR0GTpJMa1cpg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>
> > I think this would all be a nice argument to have when introducing a new
> > function. But I don't think it's a wart sufficiently big to justify
> breaking
> > compatibility.
>
> Yeah, I would side as well with the compatibility argument on this
> one.
I don't really agree with this. I think breaking compatibility in the next
major release
makes sense here. We already have pg_log_backend_memory_contexts writing to
the log, and
If we end up adding a few more functions called pg_log_something that write
to the log file,
pg_log_standby_snapshot will stand out awkwardly.
--
Sami Imseih
Amazon Web Services (AWS)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Anton A. Melnikov | 2025-04-07 01:55:45 | Re: Use XLOG_CONTROL_FILE macro everywhere? |
| Previous Message | Thomas Munro | 2025-04-07 01:33:18 | Re: Some read stream improvements |