Re: Postgresql 9.0.6 backends pruning process environment?

On Wed, Feb 15, 2012 at 06:40, dennis jenkins
<dennis(dot)jenkins(dot)75(at)gmail(dot)com> wrote:
> djenkins(at)ostara ~/code/capybara $ psql -U$someuser -dpostgres -c
> "select version();"
>                                                             version
> ----------------------------------------------------------------------------------------------------------------------------------
>  PostgreSQL 9.0.6 on x86_64-pc-linux-gnu, compiled by GCC
> x86_64-pc-linux-gnu-gcc (Gentoo 4.5.3-r1 p1.0, pie-0.4.5) 4.5.3,
> 64-bit
> (1 row)
>
> djenkins(at)ostara ~/code/capybara $ uname -a
> Linux ostara 3.1.6-gentoo #1 SMP PREEMPT Mon Jan 9 22:43:24 CST 2012
> x86_64 Intel(R) Core(TM) i5 CPU 760 @ 2.80GHz GenuineIntel GNU/Linux
>
>
>
> I recently updated my Gentoo Linux development system from postgresql
> 9.0.4 to 9.0.6-r1 (9.0.6 plus some Gentoo specific patches).  One of
> my 'C' language functions (been using it for years) stopped working
> because the backend no longer had access to the PGDATA environment
> variable.  A snippet of code is included below.
>
> My routine gathers some data about the file system that the "base"
> data directory resides on (ignoring table-spaces that could move data
> to other file systems).  The existing postgresql server admin
> functions are not sufficient to accomplish my goal:
>
> 1) "pg_database_size" does not give me all of the info that I'm after.
> 2) "pg_relation_filepath" only returns the path relative to PGDATA
> (eg, "base/nnnnn/mmmmm", not what I'm after
> ("/var/lib/postgresql/9.0", but may vary from system to system).
>
> Development on 8.4.4 through 9.0.4 worked fine.  getenv("PGDATA")
> returned a valid pathname in a shared object C function when ran by
> the back end.
>
> 9.0.6 (and 9.0.6-r1) backends appear to have no environment variables
> set in their backends.
>
> Gentoo's portage no longer has an ebuild for 9.0.4, so I reverted to
> 9.0.5.  My function resumed working again.
>
> I then tried Gentoo's portage for postgresql-9.0.6 (no -r1) and it
> failed the same (the env var is not available to the forked backend)
>
> For each postgresql version test, I recompiled and re-installed my
> function (a '.so' file).
>
> I skimmed the errata for Postgresql-9.0.6 and could not find anything
> relevant.  (http://www.postgresql.org/docs/9.0/static/release-9-0-6.html)
>
> I tried digging around in a mirrored source repository
> (https://github.com/postgres/postgres/tree/master/src) but didn't
> make much headway.
>
> Thank you for your time and thoughts.
>
>
> Questions:
>
> 1) Is the envvar present, and somehow my code or development system is faulty?
>
> 2) Were the envvars of the backends purposefully removed in version 9.0.6?

I don' trecall any such changes in PostgreSQL between those dates, and
if there were it should've been in the release notes. You can also
check the git source history for tha tbranch of course, but I doubt
you'll find anything.

I suggest you look at the version history of the gentoo packaging and
scripts instead. My guess is that something was changed there.

> 3) Is there a formal way to get the location of the "pg data dir" from
> a C language routine?

You can look at the configuration variable data_directory, or use the
C symbol DataDir which is exported from the backend.

> 4) It seems that the "cwd" (/prod/self/cwd sym link) would give me
> what I need, but can this behavior be relied on for future versions of
> Postgresql on Linux?

I have heard of no plans to change it, but I wouldn't rely on it myself.

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/