Postgresql 9.0.6 backends pruning process environment?

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?

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 ();
}