unnecessary overhead on process startup - Mailing list pgsql-general

From Frank Joerdens
Subject unnecessary overhead on process startup
Date
Msg-id 3A5097F5.A3ED7563@joerdens.de
Whole thread Raw
List pgsql-general
I just noticed that the default order in the PATH to the postgres executable may introduce
some unnecessary overhead when starting a process:

postmaster: ServerLoop:^I^Ihandling reading 4
postmaster: ServerLoop:^I^Ihandling reading 4
postmaster: ServerLoop:^I^Ihandling writing 4
postmaster: BackendStartup: pid 15909 user nobody db crewscout socket 4
postmaster child[15909]: starting with (postgres -d2 -S 2000 -v131072 -p crewscout )
FindExec: searching PATH ...
ValidateBinary: can't stat "/bin/postgres"
ValidateBinary: can't stat "/usr/bin/postgres"
ValidateBinary: can't stat "/usr/local/bin/postgres"
ValidateBinary: can't stat "/usr/bin/X11/postgres"
ValidateBinary: can't stat "/usr/X11R6/bin/postgres"
ValidateBinary: can't stat "/usr/local/sbin/postgres"
FindExec: found "/usr/local/pgsql/bin/postgres" using PATH
DEBUG:  connection: host=[local] user=nobody database=crewscout

The OS is Linux. I don't know whether this is really significant at all (because I don't
know how exactly the OS does the searching and whether the order really matters that
much), but I changed the PATH in .bash_profile for the user postgres, like

PATH=$HOME/bin:$PATH

so that /usr/local/pgsql/bin/postgres is searched first, and I get

logger: postmaster: ServerLoop:^I^Ihandling reading 4
logger: postmaster: ServerLoop:^I^Ihandling reading 4
logger: postmaster: ServerLoop:^I^Ihandling writing 4
logger: postmaster: BackendStartup: pid 15967 user nobody db crewscout socket 4
logger: postmaster child[15967]: starting with (postgres -d2 -S 2000 -v131072 -p crewscout
)
logger: FindExec: searching PATH ...
logger: FindExec: found "/usr/local/pgsql/bin/postgres" using PATH
logger: DEBUG:  connection: host=[local] user=nobody database=crewscout

which just _may_ be a little faster. Just thought it might be worth mentioning (maybe this
is really old news).

Regards, Frank

pgsql-general by date:

Previous
From: Frank Joerdens
Date:
Subject: Re: pg_dump segfaults with -z on 6.4
Next
From: Matt Beauregard
Date:
Subject: data change violation inside transaction