Thread: 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

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:

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. 

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.

-- 
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

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