CentOS initd Script

Kenaniah Cerny wrote:

I would first like to thank everyone involved for all of the hard work that goes into the postgres and
the RPMs.I have a small request:

In the service script that gets installed to /etc/rc.d/init.d/, there is a hard-coded value for
PGPORT. Would it be possible to have this variable and the corresponding -p flag set when calling
postgres removed?

Explicitly specifying the port flag causes the port setting of postgresql.conf to be ignored. When
postgresql.conf does not have the port explicitly defined, postgres falls back on the value of PGPORT,
and ultimately 5432 when PGPORT is not present in the environment.

My main use case for this request is concurrently running multiple versions of postgresql on non-
standard ports on the same box.

You should ask the people who roll the RPMs for CentOS,
they are the ones who created that script.

Yours,
Laurenz Albe

Hi,

On Wed, 2012-09-12 at 10:58 +0200, Albe Laurenz wrote:

You should ask the people who roll the RPMs for CentOS,
they are the ones who created that script.

It is actually Tom and me who are responsible for those init scripts,
CentOS does not roll their own packages.

Regards,
--
Devrim GÜNDÜZ
Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz

Hi,

On Tue, 2012-09-11 at 23:41 -0700, Kenaniah Cerny wrote:

In the service script that gets installed to /etc/rc.d/init.d/, there is a
hard-coded value for PGPORT. Would it be possible to have this variable and
the corresponding -p flag set when calling postgres removed?

Explicitly specifying the port flag causes the port setting of
postgresql.conf to be ignored. When postgresql.conf does not have the port
explicitly defined, postgres falls back on the value of PGPORT, and
ultimately 5432 when PGPORT is not present in the environment.

My main use case for this request is concurrently running multiple
versions of postgresql on non-standard ports on the same box.

Ok, this is still doable -- just change ports on both postgresql.conf
and init script, and start postmasters. I can't see why having PGPORT
in the init script prevents there.

There are some reasons for having it there, btw, like inefficiency of
parsing postgresql.conf via shell script to get the port., etc.

FWIW, Fedora switched to systemd, RHEL 7 will be switching to systemd,
too, so I'm not that much excited about changing the current behavior.

Regards,
--
Devrim GÜNDÜZ
Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz

Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= <devrim@gunduz.org> writes:

On Tue, 2012-09-11 at 23:41 -0700, Kenaniah Cerny wrote:

In the service script that gets installed to /etc/rc.d/init.d/, there is a
hard-coded value for PGPORT. Would it be possible to have this variable and
the corresponding -p flag set when calling postgres removed?

My main use case for this request is concurrently running multiple
versions of postgresql on non-standard ports on the same box.

Ok, this is still doable -- just change ports on both postgresql.conf
and init script, and start postmasters. I can't see why having PGPORT
in the init script prevents there.

There are some reasons for having it there, btw, like inefficiency of
parsing postgresql.conf via shell script to get the port., etc.

Yeah. Historically the argument for doing it like this was (1) the
script couldn't reliably get the port value out of the configure file,
and (2) if you want to run multiple postmasters, you need distinct
PGPORT and PGDATA values for each one, so it was more consistent and
convenient to specify both those things at the service-script level.

Argument (1) is obsolete since PG 9.1 or so (maybe --- systemd's lame
excuse for a scripting language would still have trouble here). But
I still find argument (2) to be pretty convincing. What's the value
of specifying the port in postgresql.conf? AFAICS that would prevent
you from using identical config files for different postmasters, with
no real benefit in return.

regards, tom lane

On Wed, Sep 12, 2012 at 12:41 AM, Kenaniah Cerny <kenaniah@gmail.com> wrote:

Hi all,

I would first like to thank everyone involved for all of the hard work that
goes into the postgres and the RPMs.I have a small request:

In the service script that gets installed to /etc/rc.d/init.d/, there is a
hard-coded value for PGPORT. Would it be possible to have this variable and
the corresponding -p flag set when calling postgres removed?

Explicitly specifying the port flag causes the port setting of
postgresql.conf to be ignored. When postgresql.conf does not have the port
explicitly defined, postgres falls back on the value of PGPORT, and
ultimately 5432 when PGPORT is not present in the environment.

My main use case for this request is concurrently running multiple versions
of postgresql on non-standard ports on the same box.

Your best bet for running > 1 versions and / or > 1 clusters of the
same version, is to run debian or any debian based distro. You create
a new cluster like so:

pg_createcluster
Usage: /usr/bin/pg_createcluster [options] <version> <cluster name>

Options:
-u <uid> cluster owner and superuser (default: 'postgres')
-g <gid> group for data files (default: primary group of owner)
-d <dir> data directory (default:
/var/lib/postgresql/<version>/<cluster name>)
-s <dir> socket directory (default: /var/run/postgresql for clusters
owned by 'postgres', /tmp for other clusters)
-l <dir> path to desired log file (default:
/var/log/postgresql/postgresql-<version>-<cluster>.log)
--locale <encoding>
set cluster locale (default: inherit from environment)
--lc-collate/ctype/messages/monetary/numeric/time <locale>
like --locale, but only set for a particular category
-e <encoding> Default encoding (default: derived from locale)
-p <port> port number (default: next free port starting from 5432)
--start start the cluster after creating it
--start-conf auto|manual|disabled
Set automatic startup behaviour in start.conf (default: 'auto')

While RHEL is a solid and reliable OS, it was never built to run > 1
version etc of pgsql easily.

On Wed, Sep 12, 2012 at 8:54 AM, Scott Marlowe <scott.marlowe@gmail.com> wrote:

Your best bet for running > 1 versions and / or > 1 clusters of the
same version, is to run debian or any debian based distro. You create
a new cluster like so:

Just a quick note that back when Centos / RHEL was my main db server
OS, I just built postgresql and slony from source so I could always
have the exact versions of each that I needed and I just used a
simplified version of the RHEL startup script to start each cluster.
It's not that hard and updating or installing a new version is as easy
as copying a configure.local file, making a few minor edits to it, and
runnning ./configure.local ; make ; make install ; mkdir /some/dir/ ;
initdb -yada ; cp /etc/init.d/pgstartupscript
/etc/init.d/pgstartupscript2 ; vi /etc/init.d/pgstartupscript2

OK not as simple as debian makes it but honestly not all that hard either.

Hi,

On Wed, September 12, 2012 5:54 pm, Scott Marlowe wrote:

While RHEL is a solid and reliable OS, it was never built to run > 1
version etc of pgsql easily.

I would disagree with this. All you need is this:

http://svn.pgrpms.org/browser/rpm/redhat/9.2/postgresql/EL-6/README.rpm-dist#L187

Regards,

--
Temporarily using a webmail program.

On Wed, Sep 12, 2012 at 9:16 AM, Devrim GUNDUZ <devrim@gunduz.org> wrote:

Hi,

On Wed, September 12, 2012 5:54 pm, Scott Marlowe wrote:

While RHEL is a solid and reliable OS, it was never built to run > 1
version etc of pgsql easily.

I would disagree with this. All you need is this:

http://svn.pgrpms.org/browser/rpm/redhat/9.2/postgresql/EL-6/README.rpm-dist#L187

or one command in debian, which has been there for years and years
(since etch at least):

pg_createcluster 9.1 mynewcluster

I stand by my opinion here. While it's nice that RH is finally
getting around to implementing something like this, I've been using it
for a long time in production in debian and debian based distros for
years with little or no issues. Does RH support > 1 cluster of the
same version of postgres yet? Looking at the link I can't really
tell. Looks like not.

Hi,

On Wed, September 12, 2012 6:49 pm, Scott Marlowe wrote:

Does RH support > 1 cluster of the same version of postgres yet?
Looking at the link I can't really tell. Looks like not.

That link exactly tells you how to do that. Running > 1 9.2 clusters in
parallel.

Regards,
--
Temporarily using a webmail program.

On Wed, Sep 12, 2012 at 9:59 AM, Devrim GUNDUZ <devrim@gunduz.org> wrote:

Hi,

On Wed, September 12, 2012 6:49 pm, Scott Marlowe wrote:

Does RH support > 1 cluster of the same version of postgres yet?
Looking at the link I can't really tell. Looks like not.

That link exactly tells you how to do that. Running > 1 9.2 clusters in
parallel.

Sorry wasn't clear. I meant does RH support running > 1 cluster of
the same version with simple commands from the command line. Like
pg_createcluster does. Of course you can run > 1 cluster if you're
willing to copy init scripts and jump through hoops, but RH is still
years behind debian on the "running > 1 postgres" front at this point.
And if you're a beginning DBA / Sysadmin it's one less thing to have
to hassle with, which is why I recommend debian for newer pg dbas who
need to build their own machines. For me personally it's no big deal
but I'm not always the guy on call either.

Hi,

On Wed, September 12, 2012 7:09 pm, Scott Marlowe wrote:

Sorry wasn't clear. I meant does RH support running > 1 cluster of
the same version with simple commands from the command line. Like
pg_createcluster does.

Well, no. Except running

cp /etc/init.d/postgresql-9.2 /etc/init.d/secondary-9.2 ; service
secondary-9.2 initdb; chkconfig secondary-9.2 on

I can create a small shell script that does it, but I never got a request
for this so far (well, this does not sound like a bad idea, let me see
what I can do tonight)

And if you're a beginning DBA / Sysadmin it's one less thing to have
to hassle with, which is why I recommend debian for newer pg dbas who
need to build their own machines.

We are going a bit offtopic, but what Debian does is not perfect, either.
Last time I checked was it was picking a random (the next available,
whatever) port when two versions are installed in parallel. Putting conf
files under /etc is also debatable at some point, since it is pretty much
in contrast to PostgreSQL docs -- so a newbie would spend some time to
find the conf files.

See? Life is not that easy on either side. "RHEL is years behind" does not
reflect the reality, IMHO.

Anyway, I'm a big fan of RHEL, so I may be a bit subjective in here :-)

Regards,
--
Temporarily using a webmail program.

Hi,

On 12 September 2012 16:41, Kenaniah Cerny <kenaniah@gmail.com> wrote:

In the service script that gets installed to /etc/rc.d/init.d/, there is a
hard-coded value for PGPORT. Would it be possible to have this variable and
the corresponding -p flag set when calling postgres removed?

My init.d script has the following:
# Set defaults for configuration variables
PGENGINE=/usr/bin
PGPORT=5432
PGDATA=/var/lib/pgsql/data
PGLOG=/var/lib/pgsql/pgstartup.log

# Override defaults from /etc/sysconfig/pgsql if file is present
[ -f /etc/sysconfig/pgsql/${NAME} ] && . /etc/sysconfig/pgsql/${NAME}

In this case you can create as many configs as you need, for example:
/etc/sysconfig/pgsql/postgresql:
PGDATA=/var/lib/pgsql/data
PGPORT=5432
PGLOG=/var/lib/pgsql/pgstartup.log
PGOPTS='--config_file=/etc/postgresql.conf'

/etc/sysconfig/pgsql/postgresql2:
PGDATA=/var/lib/pgsql2/data
PGPORT=54320
PGLOG=/var/lib/pgsql2/pgstartup.log
PGOPTS='--config_file=/etc/postgresql.conf'

and create /etc/init.d/postgresql2 as symlink to /etc/init.d/postgresql

--
Ondrej Ivanic
(ondrej.ivanic@gmail.com)