Re: pg_ctl restart - behaviour based on wrong instance

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Erik Rijkers <er(at)xs4all(dot)nl>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_ctl restart - behaviour based on wrong instance
Date: 2011-09-06 02:14:42
Message-ID: 201109060214.p862Eg623166@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas wrote:
> On Wed, Mar 23, 2011 at 1:48 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> > On Sat, Mar 19, 2011 at 10:20 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> >> On Fri, Mar 18, 2011 at 1:19 PM, Erik Rijkers <er(at)xs4all(dot)nl> wrote:
> >>> This is OK and expected. ?But then it continues (in the logfile) with:
> >>>
> >>> FATAL: ?lock file "postmaster.pid" already exists
> >>> HINT: ?Is another postmaster (PID 20519) running in data directory
> >>> "/var/data1/pg_stuff/pg_installations/pgsql.vanilla_1/data"?
> >>>
> >>> So, complaints about the *other* instance. ?It doesn't happen once a successful start (with pg_ctl
> >>> start) has happened.
> >>
> >> I'm guessing that leftover postmaster.pid contents might be
> >> responsible for this?
> >
> > The cause is that "pg_ctl restart" uses the postmaster.opts which was
> > created in the primary. Since its content was something like
> > "pg_ctl -D vanilla_1/data", vanilla_1/data/postmaster.pid was checked
> > wrongly.
> >
> > The simple workaround is to exclude postmaster.opts from the backup
> > as well as postmaster.pid. But when postmaster.opts doesn't exist,
> > "pg_ctl restart" cannot start up the server. We might also need to change
> > the code of "pg_ctl restart" so that it does just "pg_ctl start" when
> > postmaster.opts doesn't exist.
>
> Sounds reasonable.

Has this been handled?

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message daveg 2011-09-06 02:17:28 Re: [GENERAL] pg_upgrade problem
Previous Message Bruce Momjian 2011-09-06 02:08:22 Re: Shared invalidation cache messages for temporary tables