Thread: Postgresql 9.0.6 backends pruning process environment?
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 ();
}
On Wed, Feb 15, 2012 at 06:40, dennis jenkins
<dennis.jenkins.75@gmail.com> wrote:
> 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?
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/
Magnus Hagander <magnus@hagander.net> writes:
> On Wed, Feb 15, 2012 at 06:40, dennis jenkins
> <dennis.jenkins.75@gmail.com> wrote:
>> 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.
> I suggest you look at the version history of the gentoo packaging and
> scripts instead. My guess is that something was changed there.
Yes. A PG backend will not remove a "PGDATA" envar, but *it does not
set it either*. This sounds to me like a change in the startup script.
> You can look at the configuration variable data_directory, or use the
> C symbol DataDir which is exported from the backend.
Quite --- at the C level, looking at DataDir is the right thing, and
looking at PGDATA could be misleading even if it exists --- consider
the possibility that we took the data_directory setting from the
command line or postgresql.conf.
regards, tom lane
On Wed, Feb 15, 2012 at 9:18 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> On Wed, Feb 15, 2012 at 06:40, dennis jenkins
>> <dennis.jenkins.75@gmail.com> wrote:
>>> 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.
>
>> I suggest you look at the version history of the gentoo packaging and
>> scripts instead. My guess is that something was changed there.
>
> Yes. A PG backend will not remove a "PGDATA" envar, but *it does not
> set it either*. This sounds to me like a change in the startup script.
>
>> You can look at the configuration variable data_directory, or use the
>> C symbol DataDir which is exported from the backend.
>
> Quite --- at the C level, looking at DataDir is the right thing, and
> looking at PGDATA could be misleading even if it exists --- consider
> the possibility that we took the data_directory setting from the
> command line or postgresql.conf.
>
> regards, tom lane
Magnus, Tom,
Thank you very much. My code now uses 'DataDir' (export in
server/miscadmin.h) and it works fine.