On 11/20/23 12:24, Robert Haas wrote:
On Mon, Nov 20, 2023 at 5:35 AM Laurenz Albe <laurenz.a...@cybertec.at> wrote:
I can accept that adding log messages to back branches is ok.
Perhaps I am too nervous about things like that, because as an extension
developer I have been bitten too often by ABI breaks in minor releases
in the past.

I think that adding a log message to the back branches would probably
make my life better not worse, because when people do strange things
and then send me the log messages to figure out what the heck
happened, it would be there, and I'd have a clue. However, the world
doesn't revolve around me. I can imagine users getting spooked if a
new message that they've never seen before, and I think that risk
should be considered. There are good reasons for keeping the
back-branches stable, and as you said before, this isn't a bug fix.

Personally I think that the value of the information outweighs the weirdness of a new message appearing.

I do also think it is worth considering how this proposal interacts
with the proposal to remove backup_label. If that proposal goes
through, then this proposal is obsolete, I believe.

Not at all. I don't even think the messages will need to be reworded, or not much since they don't mention backup_label.

But if this is a
good idea, does that mean that's not a good idea? Or would we try to
make the pg_control which that patch would drop in place have some
internal difference which we could use to drive a similar log message?

The recovery in pg_control patch has all the same recovery info stored, so similar (or the same) log message would still be appropriate.

Maybe we should, because knowing whether or not the user followed the
backup procedure correctly would indeed be a big help and it would be
regrettable to gain that capability only to lose it again...

The info is certainly valuable and we wouldn't lose it, unless there is something I'm not getting.

Regards,
-David


Reply via email to