Thread: relocatable binary distribution
I'm making a "relocatable" Postgres binary distribution for my clients. Everything goes into postgresql-7.4.1/ directory, including libraries and binaries. This will be installed by a non-privileged user under his own home directory. The goal is that they could just extract the tarball, adjust PATH if he wants, and then just run initdb + pg_ctl start. For binaries like bin/psql or bin/pg_vacuum that needs libpq.so, I've created a C wrapper that first sets LD_LIBRARY_PATH to a relative path (../lib/) and then exec() the real binary (moved to bin/psql.real or bin/pg_vacuum.real). However, it would be nice if $libdir could be relative to the binary too. Or if there were special token too like $HOME or $execdir or $datadir that can be used in PL declaration or in postgresql.conf: dynamic_library_path = '$execdir/../lib' unix_socket_directory = '$HOME/tmp' # or e.g. '$datadir/../tmp' Where $execdir is the path of the postmaster currently running, and $datadir is the current data directory (value of -D of postmaster/pg_ctl command). (Also, I'd appreciate if someone could explain how this 'relocatability' issue is/will be tackled on Win32 port). -- dave
David Garamond said: > I'm making a "relocatable" Postgres binary distribution for my clients. > Everything goes into postgresql-7.4.1/ directory, including libraries > and binaries. This will be installed by a non-privileged user under his > own home directory. The goal is that they could just extract the > tarball, adjust PATH if he wants, and then just run initdb + pg_ctl start. > > For binaries like bin/psql or bin/pg_vacuum that needs libpq.so, I've > created a C wrapper that first sets LD_LIBRARY_PATH to a relative path > (../lib/) and then exec() the real binary (moved to bin/psql.real or > bin/pg_vacuum.real). > > However, it would be nice if $libdir could be relative to the binary > too. Or if there were special token too like $HOME or $execdir or > $datadir that can be used in PL declaration or in postgresql.conf: > > dynamic_library_path = '$execdir/../lib' > unix_socket_directory = '$HOME/tmp' # or e.g. '$datadir/../tmp' > > Where $execdir is the path of the postmaster currently running, and > $datadir is the current data directory (value of -D of postmaster/pg_ctl > command). > > (Also, I'd appreciate if someone could explain how this 'relocatability' > issue is/will be tackled on Win32 port). It seems like you could handle all the above with just a shell script wrapper. All three, the library path, socket directory, and data directory can be specified either in environment or on the command line. Where are you getting stuck? Best, Jim Wilson
Jim Wilson wrote: >>I'm making a "relocatable" Postgres binary distribution for my clients. >>Everything goes into postgresql-7.4.1/ directory, including libraries >>and binaries. This will be installed by a non-privileged user under his >>own home directory. The goal is that they could just extract the >>tarball, adjust PATH if he wants, and then just run initdb + pg_ctl start. >> >>For binaries like bin/psql or bin/pg_vacuum that needs libpq.so, I've >>created a C wrapper that first sets LD_LIBRARY_PATH to a relative path >>(../lib/) and then exec() the real binary (moved to bin/psql.real or >>bin/pg_vacuum.real). >> >>However, it would be nice if $libdir could be relative to the binary >>too. Or if there were special token too like $HOME or $execdir or >>$datadir that can be used in PL declaration or in postgresql.conf: >> >> dynamic_library_path = '$execdir/../lib' >> unix_socket_directory = '$HOME/tmp' # or e.g. '$datadir/../tmp' >> >>Where $execdir is the path of the postmaster currently running, and >>$datadir is the current data directory (value of -D of postmaster/pg_ctl >>command). >> >>(Also, I'd appreciate if someone could explain how this 'relocatability' >>issue is/will be tackled on Win32 port). > > It seems like you could handle all the above with just a shell script wrapper. > All three, the library path, socket directory, and data directory can be > specified either in environment or on the command line. Where are you getting > stuck? Ah, I should've "read the documentation for the complete list of run-time configuration settings". Didn't see -c when I ran 'postmaster --help'. Ok, now I can easily set LD_LIBRARY_PATH, socket directory, and Postgres library path. But now I'm stuck while trying to load plruby. plruby.so needs libruby.so, and this happens to be in another special location (/home/dave/opt/ruby/lib/) as the system itself doesn't have Ruby installed system-wide. I've tried adding /home/dave/opt/ruby/lib/ to LD_LIBRARY_PATH and dynamic_library_path but I still couldn't load it with "CREATE FUNCTION". (I can build plruby.so that links libruby.so statically though, so this problem is not major). BTW, I wonder why doesn't pg_ctl accept -c ? -- dave
"Jim Wilson" <jimw@kelcomaine.com> writes:
> It seems like you could handle all the above with just a shell script wrapper.
> All three, the library path, socket directory, and data directory can be
> specified either in environment or on the command line. Where are you getting
> stuck?
No, we only handle two of the three; library directory is currently
hard-coded into the server. At the moment that's seeming like a
mistake. I wonder why it's not a GUC variable (probably postmaster-only
for security). Peter, do you recall why you didn't migrate that setting
into GUC?
regards, tom lane
Tom Lane said: > "Jim Wilson" <jimw@kelcomaine.com> writes: > > It seems like you could handle all the above with just a shell script wrapper. > > All three, the library path, socket directory, and data directory can be > > specified either in environment or on the command line. Where are you getting > > stuck? > > No, we only handle two of the three; library directory is currently > hard-coded into the server. At the moment that's seeming like a > mistake. I wonder why it's not a GUC variable (probably postmaster-only > for security). Peter, do you recall why you didn't migrate that setting > into GUC? > Hmmm...I'm not sure what you mean. Is GUC a postgres thing? In any case, on the linux boxes here the libraries that the postgres executable uses seem to be standard system libraries loaded by the dynamic linker which can be configured from an environment variable. Best regards, Jim Wilson
Tom Lane wrote: >>It seems like you could handle all the above with just a shell script wrapper. >> All three, the library path, socket directory, and data directory can be >>specified either in environment or on the command line. Where are you getting >>stuck? > > No, we only handle two of the three; library directory is currently > hard-coded into the server. At the moment that's seeming like a > mistake. I wonder why it's not a GUC variable (probably postmaster-only > for security). Peter, do you recall why you didn't migrate that setting > into GUC? Yes, $libdir is hardcoded, which is why in my case I'm not using '$libdir/plruby.so' but using just 'plruby.so' (no absolute path) so Postgres can look it up with dynamic_library_path. Will this be unsafe? -- dave
David Garamond <lists@zara.6.isreserved.com> writes:
> Yes, $libdir is hardcoded, which is why in my case I'm not using
> '$libdir/plruby.so' but using just 'plruby.so' (no absolute path) so
> Postgres can look it up with dynamic_library_path. Will this be unsafe?
Seems like an okay workaround for now.
regards, tom lane