Thread: Voting: "pg_ctl init" versus "initdb"
Hi all,
I prepared patch which extend pg_ctl functionality and add "init"
command which do same thing like initdb (it calls initdb on the
background). The idea behind this is to have only one command which
control database. pg_ctl already has "start", "stop", "restart",
"reload" and so on. To have "init" is logical. There is also second
reason for that. Initdb does not fit pg binaries naming convection which
could lead to name conflict in the /usr/bin.
Because there is doubt if someone else want this I would like to ask
here for your opinion. There are following options:
1) Yeah I like pg_ctl init
"pg_ctl init" will be preferred method and initdb will
disappear from usr/bin in the future.
2) Good, but keep initdb as well
pg_ctl init and initdb stays forever
3) Do not touch my lovely initdb
pg_ctl init is nonsense, initdb is only correct way.
Thanks for your response
Zdenek
Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes:
> Because there is doubt if someone else want this I would like to ask
> here for your opinion. There are following options:
> 1) Yeah I like pg_ctl init
> "pg_ctl init" will be preferred method and initdb will
> disappear from usr/bin in the future.
> 2) Good, but keep initdb as well
> pg_ctl init and initdb stays forever
> 3) Do not touch my lovely initdb
> pg_ctl init is nonsense, initdb is only correct way.
You have listed them in reverse preference order ;-)
The only people who would actually care about this are packagers
who think they can get away with taking initdb out of $PATH.
If you believe that you can get away with that, you can do it today
without any help from pg_ctl. (Your theory presumably is that only
one place in the initscript needs to know about it, and that one place
could just as easily invoke initdb with an explicit path to wherever.)
If you don't believe that you can get away with hiding initdb out of
sight, then this patch is useless to you.
(BTW, have you actually tried moving initdb? I wonder how well the
relative-path logic for finding SHAREDIR etc is going to cope.)
So I find the patch pretty useless. But it's also pretty harmless,
so long as it doesn't extend to the idea that we'd actually hide
initdb in a default installation; at that point you're going to start
hitting stiff resistance.
regards, tom lane
Zdenek Kotala wrote: > 1) Yeah I like pg_ctl init > > "pg_ctl init" will be preferred method and initdb will > disappear from usr/bin in the future. I agree with this position. My own database wrapper scripts work this way already, and it would be nice for them to have one more command that maps directly to a pg_ctl call rather than needing to special-case initdb instead. There's also the precedent that the RPM scripts provide an "initdb" target so that the user doesn't need to know how to use initdb directly; in the field, that's what I tell people to use when in an RPM environment, rather than calling initdb directly. I believe that the fact that there's this separate binary named "initdb" you only call once, and that has a name unlike all of the rest of the binaries, would be considered a bad design were that decision being made from a UI and packaging perspective right now. Zdenek is completely correct to identify this inconsistency, the tiny bump it adds to the learning curve, and the difficulty it adds to packaging as things that should be improved. Every unique thing you have to know in order to start using the database costs a little bit of time, and I'm always in favor of anything that removes one of those from the list, even if it's a small one. If anything, I think you're not going far enough. Not only should "pg_ctl init" work, "pg_ctl start" should be more helpful in the way "service postgresql start" is--suggesting to the user that they need the init step if the cluster doesn't exist. That said, I wouldn't even bother trying to get such a change committed, as this project actively resists changes that impact backward compatibility merely to improve the inexperienced user experience. It will be an uphill battle the whole way, beset by people who don't have to spend enough time with PostgreSQL newbies enough to appreciate what they struggle with. If I could avoid having to teaching them initdb, and instead just mention it as another option during the pg_ctl lesson, that would be one less thing to have to train on. -- Greg Smith 2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.com
On Sat, 2009-11-14 at 15:07 +0100, Zdenek Kotala wrote: > extend pg_ctl functionality and add "init" command which do same thing > like initdb If we did add an extra option then the option would be "initdb" not "init". It would take us all years to remove all evidence of the phrase "initdb" from the mailing lists and our minds. -- Simon Riggs www.2ndQuadrant.com
Simon Riggs <simon@2ndQuadrant.com> writes:
> On Sat, 2009-11-14 at 15:07 +0100, Zdenek Kotala wrote:
>> extend pg_ctl functionality and add "init" command which do same thing
>> like initdb
> If we did add an extra option then the option would be "initdb" not
> "init". It would take us all years to remove all evidence of the phrase
> "initdb" from the mailing lists and our minds.
"init" is already embedded in various packagers' initscripts. And
I thought the entire point of this proposal was that we could expunge
knowledge of initdb from users' minds. (I'm dubious of that too,
but varying from what's already established at the script level will
not help.)
regards, tom lane
Tom Lane wrote:
Exactly. I think the best transition design would be to make "initdb" and "init" both work.Simon Riggs <simon@2ndQuadrant.com> writes:If we did add an extra option then the option would be "initdb" not "init". It would take us all years to remove all evidence of the phrase "initdb" from the mailing lists and our minds."init" is already embedded in various packagers' initscripts. And I thought the entire point of this proposal was that we could expunge knowledge of initdb from users' minds.
-- Greg Smith 2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.com
On Nov 14, 8:07 am, Zdenek.Kot...@Sun.COM (Zdenek Kotala) wrote: > Hi all, > > <snip> > Because there is doubt if someone else want this I would like to ask > here for your opinion. There are following options: > > 1) Yeah I like pg_ctl init > > "pg_ctl init" will be preferred method and initdb will > disappear from usr/bin in the future. > > 2) Good, but keep initdb as well > > pg_ctl init and initdb stays forever > > 3) Do not touch my lovely initdb > > pg_ctl init is nonsense, initdb is only correct way. > > Thanks for your response > > Zdenek > <snip> I would be in the group that says 3,2,1. I just don't see a big advantage to what you are suggesting. Loyal
Tom Lane píše v so 14. 11. 2009 v 11:22 -0500:
> Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes:
> > Because there is doubt if someone else want this I would like to ask
> > here for your opinion. There are following options:
>
> > 1) Yeah I like pg_ctl init
>
> > "pg_ctl init" will be preferred method and initdb will
> > disappear from usr/bin in the future.
>
> > 2) Good, but keep initdb as well
>
> > pg_ctl init and initdb stays forever
>
> > 3) Do not touch my lovely initdb
>
> > pg_ctl init is nonsense, initdb is only correct way.
>
> You have listed them in reverse preference order ;-)
Maybe because I'm sitting on opposite hemisphere :-)
> The only people who would actually care about this are packagers
> who think they can get away with taking initdb out of $PATH.
> If you believe that you can get away with that, you can do it today
> without any help from pg_ctl. (Your theory presumably is that only
> one place in the initscript needs to know about it, and that one place
> could just as easily invoke initdb with an explicit path to wherever.)
> If you don't believe that you can get away with hiding initdb out of
> sight, then this patch is useless to you.
init script is not only one place when you need initdb. init script can
do it for you but often you need to setup correct locale. And admins
need to init database manually. And after that they want to have command
for it in default path.
Another advantage of pg_ctl is that it is easy to extend it to cope with
more postgres versions and calls appropriate version of postgres or
initdb.
>
> (BTW, have you actually tried moving initdb? I wonder how well the
> relative-path logic for finding SHAREDIR etc is going to cope.)
libexecdir is not used. find_other_exec() is little bit stupid. It
finds only binaries in the same directory. I guess It should look into
bindir and libexecdir as well.
when I'm thinking about it postgres and initdb should be installed into
libexecdir instead of bindir. For example sshd is in /usr/lib/sshd/ on
solaris.
> So I find the patch pretty useless. But it's also pretty harmless,
> so long as it doesn't extend to the idea that we'd actually hide
> initdb in a default installation; at that point you're going to start
> hitting stiff resistance.
I supposed to use libexecdir for installation. If packager wants to hide
it than he can set libexecdir to another place. If not initdb will stay
in bindir.
Zdenek
Greg Smith píše v ne 15. 11. 2009 v 22:16 -0500:
> Tom Lane wrote:
> > Simon Riggs <simon@2ndQuadrant.com> writes:
> >
> > > If we did add an extra option then the option would be "initdb" not
> > > "init". It would take us all years to remove all evidence of the phrase
> > > "initdb" from the mailing lists and our minds.
> > >
> >
> > "init" is already embedded in various packagers' initscripts. And
> > I thought the entire point of this proposal was that we could expunge
> > knowledge of initdb from users' minds.
> Exactly. I think the best transition design would be to make "initdb"
> and "init" both work.
"initdb" sounds me now better then "init", but to have both is
technically not problem. But question is if it is less confusing than
have only one of them.
Just a note that we already have WAL/XLOG or
postgres/postmaster/frontend/backend.
Zdenek