Обсуждение: Exposing an installation's default value of unix_socket_directory
I just noticed that there doesn't seem to be any good way of finding
out what a postmaster's default value of unix_socket_directory is.
If you try to SHOW it you just get an empty string. We could probably
fix things so that SHOW exposes the actual setting, but (1) there might
be security arguments against that, and (2) if your problem is that you
would like to find out the value so's you can connect to said
postmaster, SHOW isn't going to help you.
One possible response would be to add an item to what pg_config knows
about, eg "pg_config --socketdir". This doesn't answer every possible
use-case either, but it would be helpful for some scenarios.
Thoughts?
regards, tom lane
2010/10/21 Tom Lane <tgl@sss.pgh.pa.us>: > I just noticed that there doesn't seem to be any good way of finding > out what a postmaster's default value of unix_socket_directory is. > If you try to SHOW it you just get an empty string. We could probably > fix things so that SHOW exposes the actual setting, but (1) there might > be security arguments against that, and (2) if your problem is that you > would like to find out the value so's you can connect to said > postmaster, SHOW isn't going to help you. > > One possible response would be to add an item to what pg_config knows > about, eg "pg_config --socketdir". This doesn't answer every possible > use-case either, but it would be helpful for some scenarios. > > Thoughts? I agree this is interesting information to get, but wonder how pg_config can know that and it looks to me that this information as nothing to do in pg_config.... pg_config is all about installation, socket_dir is a postgresql.conf setting. I'd prefer a 'pg_ctl status' output. > > regards, tom lane > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- Cédric Villemain 2ndQuadrant http://2ndQuadrant.fr/ PostgreSQL : Expertise, Formation et Support
Excerpts from Cédric Villemain's message of jue oct 21 16:01:30 -0300 2010: > I agree this is interesting information to get, but wonder how > pg_config can know that and it looks to me that this information as > nothing to do in pg_config.... > > pg_config is all about installation, socket_dir is a postgresql.conf setting. Yeah -- how is pg_config to know? All it can tell you is what was the compiled-in default. pg_ctl would be nice, but we'd have to make it parse the config file (there has been talk about that). In any case, if you don't know where the socket is, presumably you don't know where the config file is, either. You've just moved the problem. Maybe you should go the SHOW route. The user could connect via TCP and find out the socket directory that way. -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Tom Lane <tgl@sss.pgh.pa.us> writes: > One possible response would be to add an item to what pg_config knows > about, eg "pg_config --socketdir". This doesn't answer every possible > use-case either, but it would be helpful for some scenarios. > > Thoughts? Following some links one can find out http://packages.debian.org/source/unstable/postgresql-9.0 http://ftp.de.debian.org/debian/pool/main/p/postgresql-9.0/postgresql-9.0_9.0.1-1.debian.tar.gz And check that debian package is patching src/include/pg_config_manual.h and not using the other facility proposed in the comments: * here's where to twiddle it. You can also override this at runtime* with the postmaster's -k switch. -#define DEFAULT_PGSOCKET_DIR "/tmp" +#define DEFAULT_PGSOCKET_DIR "/var/run/postgresql" But still, I wonder how this -k switch will get a role here, pg_control certainly won't know about that. I guess it's worse to give a wrong value rather than none, but that's easy to fix by having a good label for the line, I guess. All in all it would be good to have that in pg_control. -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
Alvaro Herrera <alvherre@commandprompt.com> writes:
> Excerpts from Cédric Villemain's message of jue oct 21 16:01:30 -0300 2010:
>> I agree this is interesting information to get, but wonder how
>> pg_config can know that and it looks to me that this information as
>> nothing to do in pg_config....
>>
>> pg_config is all about installation, socket_dir is a postgresql.conf setting.
> Yeah -- how is pg_config to know? All it can tell you is what was the
> compiled-in default.
That's what I wanted, actually. If you've set a non-default value in
postgresql.conf, SHOW will tell you about that, but it fails to expose
the default value.
> Maybe you should go the SHOW route. The user could connect via TCP and
> find out the socket directory that way.
Yeah, the SHOW case is not useless by any means.
regards, tom lane
2010/10/21 Tom Lane <tgl@sss.pgh.pa.us>: > Alvaro Herrera <alvherre@commandprompt.com> writes: >> Excerpts from Cédric Villemain's message of jue oct 21 16:01:30 -0300 2010: >>> I agree this is interesting information to get, but wonder how >>> pg_config can know that and it looks to me that this information as >>> nothing to do in pg_config.... >>> >>> pg_config is all about installation, socket_dir is a postgresql.conf setting. > >> Yeah -- how is pg_config to know? All it can tell you is what was the >> compiled-in default. > > That's what I wanted, actually. If you've set a non-default value in > postgresql.conf, SHOW will tell you about that, but it fails to expose > the default value. > >> Maybe you should go the SHOW route. The user could connect via TCP and >> find out the socket directory that way. > > Yeah, the SHOW case is not useless by any means. I think adding this to pg_config is sensible. Sure, the user could have moved the socket directory. But it's a place to start looking. So why not? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Oct 21, 2010, at 4:19 PM, Robert Haas wrote: > 2010/10/21 Tom Lane <tgl@sss.pgh.pa.us>: >> Alvaro Herrera <alvherre@commandprompt.com> writes: >>> Excerpts from Cédric Villemain's message of jue oct 21 16:01:30 -0300 2010: >>>> I agree this is interesting information to get, but wonder how >>>> pg_config can know that and it looks to me that this information as >>>> nothing to do in pg_config.... >>>> >>>> pg_config is all about installation, socket_dir is a postgresql.conf setting. >> >>> Yeah -- how is pg_config to know? All it can tell you is what was the >>> compiled-in default. >> >> That's what I wanted, actually. If you've set a non-default value in >> postgresql.conf, SHOW will tell you about that, but it fails to expose >> the default value. >> >>> Maybe you should go the SHOW route. The user could connect via TCP and >>> find out the socket directory that way. >> >> Yeah, the SHOW case is not useless by any means. > > I think adding this to pg_config is sensible. Sure, the user could > have moved the socket directory. But it's a place to start looking. > So why not? Because pg_config is supposed to return the current state of a cluster? Because it might indicate a connection to the wrong server? Cheers, M
"A.M." <agentm@themactionfaction.com> writes:
> On Oct 21, 2010, at 4:19 PM, Robert Haas wrote:
>> I think adding this to pg_config is sensible. Sure, the user could
>> have moved the socket directory. But it's a place to start looking.
>> So why not?
> Because pg_config is supposed to return the current state of a cluster?
pg_config is not supposed to do any such thing. It exists specifically
and solely to tell you about build options that were baked into the
compiled code.
Actually, the only reason this is even up for discussion is that there's
no configure option to set DEFAULT_PGSOCKET_DIR. If there were, and
debian were using it, then pg_config --configure would tell what I wish
to know. I thought for a bit about proposing we add such an option,
but given the current state of play it might be more misleading than
helpful: as long as distros are accustomed to changing this setting via
a patch, you couldn't trust pg_config --configure to tell you what a
given installation actually has compiled into it.
regards, tom lane
On tor, 2010-10-21 at 16:59 -0400, Tom Lane wrote: > Actually, the only reason this is even up for discussion is that > there's > no configure option to set DEFAULT_PGSOCKET_DIR. If there were, and > debian were using it, then pg_config --configure would tell what I > wish > to know. I thought for a bit about proposing we add such an option, > but given the current state of play it might be more misleading than > helpful: as long as distros are accustomed to changing this setting > via > a patch, you couldn't trust pg_config --configure to tell you what a > given installation actually has compiled into it. Presumably, if a configure option were added, they couldn't change it via patch anymore. Of course, there will be a transition period, but there will have to be one of some kind anyway. Btw., a configure option for this was rejected years ago to discourage people from actually changing the default.
Peter Eisentraut <peter_e@gmx.net> writes:
> On tor, 2010-10-21 at 16:59 -0400, Tom Lane wrote:
>> Actually, the only reason this is even up for discussion is that
>> there's
>> no configure option to set DEFAULT_PGSOCKET_DIR. If there were, and
>> debian were using it, then pg_config --configure would tell what I
>> wish
>> to know. I thought for a bit about proposing we add such an option,
>> but given the current state of play it might be more misleading than
>> helpful: as long as distros are accustomed to changing this setting
>> via
>> a patch, you couldn't trust pg_config --configure to tell you what a
>> given installation actually has compiled into it.
> Presumably, if a configure option were added, they couldn't change it
> via patch anymore.
Hm, you're right: we'd remove the pg_config_manual.h entry, so the
existing patches would stop working, and presumably maintainers would
figure out that they ought to use the configure switch instead. So
that argument holds little water.
> Btw., a configure option for this was rejected years ago to discourage
> people from actually changing the default.
Yeah, I remember that discussion now that you mention it. It still
seems like a good policy ... but given that some popular packages are
changing the default whether we think it's a good idea or not, maybe
it's better to acknowledge that reality. We could still have some
text in the manual pointing out the compatibility hazards of using
the switch, I guess.
regards, tom lane
Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.net> writes: > > On tor, 2010-10-21 at 16:59 -0400, Tom Lane wrote: > >> Actually, the only reason this is even up for discussion is that > >> there's > >> no configure option to set DEFAULT_PGSOCKET_DIR. If there were, and > >> debian were using it, then pg_config --configure would tell what I > >> wish > >> to know. I thought for a bit about proposing we add such an option, > >> but given the current state of play it might be more misleading than > >> helpful: as long as distros are accustomed to changing this setting > >> via > >> a patch, you couldn't trust pg_config --configure to tell you what a > >> given installation actually has compiled into it. > > > Presumably, if a configure option were added, they couldn't change it > > via patch anymore. > > Hm, you're right: we'd remove the pg_config_manual.h entry, so the > existing patches would stop working, and presumably maintainers would > figure out that they ought to use the configure switch instead. So > that argument holds little water. > > > Btw., a configure option for this was rejected years ago to discourage > > people from actually changing the default. > > Yeah, I remember that discussion now that you mention it. It still > seems like a good policy ... but given that some popular packages are > changing the default whether we think it's a good idea or not, maybe > it's better to acknowledge that reality. We could still have some > text in the manual pointing out the compatibility hazards of using > the switch, I guess. Might have been a nice change for 9.0. :-( I don't think there is a great amount of defense that it should be in /tmp except for backward compatibility, and for non-root installs. For a package installer, I think moving it out of temp makes sense, hence a configure flag. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Added to TODO: Allow simpler reporting of the unix domain socket directory and alloweasier configuration of its default location * http://archives.postgresql.org/pgsql-hackers/2010-10/msg01555.php --------------------------------------------------------------------------- Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.net> writes: > > On tor, 2010-10-21 at 16:59 -0400, Tom Lane wrote: > >> Actually, the only reason this is even up for discussion is that > >> there's > >> no configure option to set DEFAULT_PGSOCKET_DIR. If there were, and > >> debian were using it, then pg_config --configure would tell what I > >> wish > >> to know. I thought for a bit about proposing we add such an option, > >> but given the current state of play it might be more misleading than > >> helpful: as long as distros are accustomed to changing this setting > >> via > >> a patch, you couldn't trust pg_config --configure to tell you what a > >> given installation actually has compiled into it. > > > Presumably, if a configure option were added, they couldn't change it > > via patch anymore. > > Hm, you're right: we'd remove the pg_config_manual.h entry, so the > existing patches would stop working, and presumably maintainers would > figure out that they ought to use the configure switch instead. So > that argument holds little water. > > > Btw., a configure option for this was rejected years ago to discourage > > people from actually changing the default. > > Yeah, I remember that discussion now that you mention it. It still > seems like a good policy ... but given that some popular packages are > changing the default whether we think it's a good idea or not, maybe > it's better to acknowledge that reality. We could still have some > text in the manual pointing out the compatibility hazards of using > the switch, I guess. > > regards, tom lane > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +