Greetings, * Robert Haas (robertmh...@gmail.com) wrote: > On Tue, Oct 8, 2019 at 9:58 AM Stephen Frost <sfr...@snowman.net> wrote: > > From a user > > perspective, what happens when you've started up PG as a primary, since > > you don't have a signal file in place to indicate that you're doing > > recovery, and you have a recovery_target set, so some user does > > "show recovery_target_name" and sees a value? How is that sensible? > > I'd argue that not only is it sensible, but it's the only correct > answer. If I put a value in postgresql.conf and it doesn't show up in > the output of SHOW, I'm going to be confused. That just seems flat > wrong to me.
You're going to be really confused when you realize that, sure, it's set, but we just completely ignored it ... How about we look at things like listen_addresses or shared_buffers? Let's make a similar argument there- some day, in the future, we make PG automagically realize when shared_buffers is too high to be able to start up, so we lower it to some other value just to get the database online, with the hope that the user will realize and fix the setting (this isn't a joke- having shared_buffers be too high through an ALTER SYSTEM setting is a real problem and it'd be nice if we had a way to deal with that...), you think we should keep the shared_buffers variable showing whatever was in the config file because, well, that's what was in the config file? If anything, what we should be doing here is throwing a WARNING or similar that these settings don't make sense, because we aren't going through recovery, and blank them out. If we want to be really cute, we could have the show return something like: <not in recovery>, or similar, but just returning an invalid value because that's what was in the config file is nonsense. SHOW isn't a view of what's in postgresql.conf, it's telling the user what the current system state is. Thanks, Stephen
signature.asc
Description: PGP signature
