Postgresql 9.0.6 backends pruning process environment? - Mailing list pgsql-general

djenkins@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@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?

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

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?


ostara ~ # ls -l /proc/2384/cwd
lrwxrwxrwx 1 postgres postgres 0 Feb 14 23:38 /proc/2384/cwd ->
/var/lib/postgresql/9.0/data

ostara ~ # cat /proc/2384/environ

ostara ~ # equery l '*postgresql*'
 * Searching for *postgresql* ...
[IP-] [  ] app-admin/eselect-postgresql-1.0.10:0
[IP-] [  ] dev-db/postgresql-base-9.0.6:9.0
[IP-] [  ] dev-db/postgresql-base-9.1.2:9.1
[IP-] [  ] dev-db/postgresql-server-9.0.6:9.0
[IP-] [  ] dev-db/postgresql-server-9.1.2-r2:9.1




Datum           backend_disk_stats (PG_FUNCTION_ARGS)
{
        char            *pgdatadir = NULL;
        struct statvfs  vfs;
        TupleDesc       tupdesc = NULL;         // Custom PG data type
"disk_stats"
        AttInMetadata   *attinmeta = NULL;      // Used for accessing
composit type members by name.
        Datum           result;
        HeapTuple       tuple;
        char            **values = NULL;
        int             i = 0;
        u_int64_t       nUsed = 0;

        if (NULL == (pgdatadir = getenv ("PGDATA")))
        {
                elog (ERROR, "getenv('PGDATA') failed.\n");
                PG_RETURN_NULL ();
        }

        if (-1 == statvfs (pgdatadir, &vfs))
        {
                elog (ERROR, "statvfs() failed.\n");
                PG_RETURN_NULL ();
        }