Re: Is it possible to control the location of the lock file when starting postgres?

From: John R Pierce <pierce(at)hogranch(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: Is it possible to control the location of the lock file when starting postgres?
Date: 2016-07-21 00:03:38
Message-ID: 87b606f6-0ef9-8c49-3bbb-4ebfadbba325@hogranch.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 7/20/2016 4:48 PM, Steve Langlois wrote:
> I am upgrading an existing system running CentOS 5.6 with Postgres
> 8.2.5 to CentOS 7 with 9.2.15. The original system modified the
> postgresql script to manually running postmaster to start the database
> under the current user control. So it is really for compatibility with
> the rest of the code.

'because we did it this way 10 years ago' is a lousy excuse, but whatever.

if you're upgrading the OS and database and everything, why are you
stopping at 9.2? that version is already 80% through its support life
cycle, I would use 9.4 or 9.5 for maximum support longetivity. 9.1 is
on its final release, 9.2 will likely be desupported in a year or so.

>
> So currently to create the database I run:
>
> /usr/bin/initdb --pgdata=/usr/test/databases/pgsql/data --auth=ident
>
> And to start the database with:
>
> /usr/bin/postmaster -p 5432 -D /usr/test/databases/pgsql/data
>
> If local is used for unix domain socket connections do I change --auth
> to --auth-local=ident for initdb?

to work with the standard centos/rhel builds, you should use su or sudo
to run those commands as the postgres user, rather than whatever this
current user is, otherwise you'll be in a continuous world of hurt.
really, its much easier to just use the systemctl stuff to start/stop.

--
john r pierce, recycling bits in santa cruz

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Steve Langlois 2016-07-21 00:12:06 Re: Is it possible to control the location of the lock file when starting postgres?
Previous Message Adrian Klaver 2016-07-20 23:53:07 Re: High Availability