Обсуждение: Finding the bin path
Is there a command or reliable method of finding the location of the PostgreSQL bin path?
I'm currently using "SHOW hba_file;" which gives me the data path. For default installs I can find the bin relative to this, but it fails under custom installs.
My apologies if this has been addressed before, but I could not find it in a search.
- Rob
I'm currently using "SHOW hba_file;" which gives me the data path. For default installs I can find the bin relative to this, but it fails under custom installs.
My apologies if this has been addressed before, but I could not find it in a search.
- Rob
Rob Jaeger wrote: > Is there a command or reliable method of finding the location of the > PostgreSQL bin path? > > I'm currently using "SHOW hba_file;" which gives me the data path. For > default installs I can find the bin relative to this, but it fails > under custom installs. > > My apologies if this has been addressed before, but I could not find > it in a search. actually in some configurations (debian/ubuntu for instance) the .CONF files like pg_hba, aren't stored in the $PGDATA directory either, they are in /etc/postgresql/<ver>/ or something.
Le 25/12/2009 18:02, Rob Jaeger a écrit : > Is there a command or reliable method of finding the location of the > PostgreSQL bin path? > Nope. > I'm currently using "SHOW hba_file;" which gives me the data path. For > default installs I can find the bin relative to this, but it fails under > custom installs. > It doesn't give you the path to to data directory. It gives you the path to the pg_hba.conf file. If you want the data directory path, use SHOW data_directory. -- Guillaume. http://www.postgresqlfr.org http://dalibo.com
Rob Jaeger <yogirob@gmail.com> writes: > Is there a command or reliable method of finding the location of the > PostgreSQL bin path? pg_config --bindir Although I think not all packagers install this in the base package, which might limit its usefulness. regards, tom lane
Tom Lane wrote:
1) Where can I find the PostgreSQL in my PATH right now? The best I think you can do here is to try the above pg_config bit first, then if it doesn't work try guess based on "which postmaster".
2) Given a running server, what PostgreSQL binary was used to start it? You can get some info about a running server using this query (which just suggests what SHOW can give you):
select name,setting from pg_settings where category='File Locations';
But there's no binary location listed there. You can dig it out of ps using something like this:
ps -C postgres -o cmd 2>&1 | grep "/postgres" | cut -d" " -f1
(Tested on Linux)
You'll need to test on all the UNIX-ish OSes you want to support though, getting ps calls to work perfectly everywhere is harder than it should be.
Only the pg_config technique will be easy to use from Windows I think, but at least there you shouldn't have as many concerns about what subsets of the package are installed--I don't think it's sliced up nearly as fine as you can make the RPM or deb installs for example, such that you can easily have a server running but not pg_config. I could be wrong about that though.
I'm not sure which question Rob meant to ask here:Rob Jaeger <yogirob@gmail.com> writes:Is there a command or reliable method of finding the location of the PostgreSQL bin path?pg_config --bindir Although I think not all packagers install this in the base package, which might limit its usefulness.
1) Where can I find the PostgreSQL in my PATH right now? The best I think you can do here is to try the above pg_config bit first, then if it doesn't work try guess based on "which postmaster".
2) Given a running server, what PostgreSQL binary was used to start it? You can get some info about a running server using this query (which just suggests what SHOW can give you):
select name,setting from pg_settings where category='File Locations';
But there's no binary location listed there. You can dig it out of ps using something like this:
ps -C postgres -o cmd 2>&1 | grep "/postgres" | cut -d" " -f1
(Tested on Linux)
You'll need to test on all the UNIX-ish OSes you want to support though, getting ps calls to work perfectly everywhere is harder than it should be.
Only the pg_config technique will be easy to use from Windows I think, but at least there you shouldn't have as many concerns about what subsets of the package are installed--I don't think it's sliced up nearly as fine as you can make the RPM or deb installs for example, such that you can easily have a server running but not pg_config. I could be wrong about that though.
-- Greg Smith 2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.com
Greg Smith wrote: > I'm not sure which question Rob meant to ask here: > > 1) Where can I find the PostgreSQL in my PATH right now? The best I > think you can do here is to try the above pg_config bit first, then if > it doesn't work try guess based on "which postmaster". > > 2) Given a running server, what PostgreSQL binary was used to start > it? You can get some info about a running server using this query > (which just suggests what SHOW can give you): > > select name,setting from pg_settings where category='File Locations'; > > But there's no binary location listed there. You can dig it out of ps > using something like this: > > ps -C postgres -o cmd 2>&1 | grep "/postgres" | cut -d" " -f1 > (Tested on Linux) > > You'll need to test on all the UNIX-ish OSes you want to support > though, getting ps calls to work perfectly everywhere is harder than > it should be. > > Only the pg_config technique will be easy to use from Windows I think, > but at least there you shouldn't have as many concerns about what > subsets of the package are installed--I don't think it's sliced up > nearly as fine as you can make the RPM or deb installs for example, > such that you can easily have a server running but not pg_config. I > could be wrong about that though. and for extra confusion, its perfectly feasible for more than one postgres server to be running at the same time, from different paths. I do wonder... why would an application -care- where the server daemon is running from?
I was not clear in my initial question. I need to access the pg_dump.exe and pg_restore.exe files from within a c++ program. I can't execute pg_config.exe because it's in that bin that I'm seeking.
I don't quite follow Greg Smith's reply of 'try guess based on "which postmaster"' (can you clarify?)
But - I think I have found what I need! I can do a "SHOW data_directory;" and then from there I can snoop inside the postmaster.opts file to get the bin path. The question I have now is - is this method safe? Is this file present in all platform data directories. (I'm using Win7)
Thanks to everyone who replied. I really do appreciate this community. - Rob
I don't quite follow Greg Smith's reply of 'try guess based on "which postmaster"' (can you clarify?)
But - I think I have found what I need! I can do a "SHOW data_directory;" and then from there I can snoop inside the postmaster.opts file to get the bin path. The question I have now is - is this method safe? Is this file present in all platform data directories. (I'm using Win7)
Thanks to everyone who replied. I really do appreciate this community. - Rob
On Sat, Dec 26, 2009 at 5:54 PM, Greg Smith <greg@2ndquadrant.com> wrote:
Tom Lane wrote:Rob Jaeger <yogirob@gmail.com> writes:Is there a command or reliable method of finding the location of the PostgreSQL bin path?
Rob Jaeger wrote: > I was not clear in my initial question. I need to access the > pg_dump.exe and pg_restore.exe files from within a c++ program. I > can't execute pg_config.exe because it's in that bin that I'm seeking. > > I don't quite follow Greg Smith's reply of 'try guess based on "which > postmaster"' (can you clarify?) > $ which postmaster /usr/bin/postmaster the which command on most unix platforms searches the PATH > But - I think I have found what I need! I can do a "SHOW > data_directory;" and then from there I can snoop inside the > postmaster.opts file to get the bin path. The question I have now is - > is this method safe? Is this file present in all platform data > directories. (I'm using Win7) its there on a RHEL/CentOS/Fedora default install... $ more $PGDATA/postmaster.opts /usr/bin/postgres "-p" "5432" "-D" "/var/lib/pgsql/data" the one I'd be worried about would be a debian/ubuntu install as they move stuff around all over the place and can support several concurrent installations.
On 27/12/2009 2:12 PM, Rob Jaeger wrote: > I don't quite follow Greg Smith's reply of 'try guess based on "which > postmaster"' (can you clarify?) He's talking about UNIX systems. This will not help you. > But - I think I have found what I need! I can do a "SHOW > data_directory;" and then from there I can snoop inside the > postmaster.opts file to get the bin path. The question I have now is - > is this method safe? Is this file present in all platform data > directories. (I'm using Win7) It looks like it's present on all platforms. There are the contents for my Debian (Linux) system: /usr/lib/postgresql/8.4/bin/postgres "-D" "/var/lib/postgresql/8.4/main" "-c" "config_file=/etc/postgresql/8.4/main/postgresql.conf" The release notes say that postmaster.opts was added in 7.0, so it'll be present for any version remotely new enough to still be in reasonable use. -- Craig Ringer
On 27/12/2009 2:12 PM, Rob Jaeger wrote: > I was not clear in my initial question. I need to access the pg_dump.exe > and pg_restore.exe files from within a c++ program. I can't execute > pg_config.exe because it's in that bin that I'm seeking. > > I don't quite follow Greg Smith's reply of 'try guess based on "which > postmaster"' (can you clarify?) > > But - I think I have found what I need! I can do a "SHOW > data_directory;" and then from there I can snoop inside the > postmaster.opts file to get the bin path. The question I have now is - > is this method safe? Is this file present in all platform data > directories. (I'm using Win7) Oh, I just thought: what if your app isn't being run on the same host as the database server? If the database server isn't even on the same kind of platform? What if (as is quite likely) the data directory is locked down so that user running your program does not have permission to access it, even though it is on the same computer? You need to provide preferences to let the user override the auto-detected paths to pg_dump and pg_restore, so this can be handled. I also suggest checking %ProgramFiles%\PostgreSQL\<largest-version-number>\bin for `pg_dump.exe' and `pg_restore.exe' if you can't access postmaster.opts. You will need to detect and warn about the case where pg_dump is older than the database being connected to. It's fine if it's newer, but it should not be older. -- Craig Ringer