Robert Haas wrote:
> On Wed, Mar 23, 2011 at 1:48 AM, Fujii Masao <masao.fu...@gmail.com> wrote:
> > On Sat, Mar 19, 2011 at 10:20 AM, Robert Haas <robertmh...@gmail.com> wrote:
> >> On Fri, Mar 18, 2011 at 1:19 PM, Erik Rijkers <e...@xs4all.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.
I looked over this issue and I don't thinking having pg_ctl restart fall
back to 'start' is a good solution. I am concerned about cases where we
start a different server without shutting down the old server, for some
reason. When they say 'restart', I think we have to assume they want a
restart.
What I did do was to document that not backing up postmaster.pid and
postmaster.opts might help prevent pg_ctl from getting confused.
Patch applied and backpatched to 9.1.X.
--
Bruce Momjian <br...@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
diff --git a/doc/src/sgml/backup.sgml b/doc/src/sgml/backup.sgml
new file mode 100644
index b8daedc..737355a
*** a/doc/src/sgml/backup.sgml
--- b/doc/src/sgml/backup.sgml
*************** SELECT pg_stop_backup();
*** 869,875 ****
of mistakes when restoring. This is easy to arrange if
<filename>pg_xlog/</> is a symbolic link pointing to someplace outside
the cluster directory, which is a common setup anyway for performance
! reasons.
</para>
<para>
--- 869,879 ----
of mistakes when restoring. This is easy to arrange if
<filename>pg_xlog/</> is a symbolic link pointing to someplace outside
the cluster directory, which is a common setup anyway for performance
! reasons. You might also want to exclude <filename>postmaster.pid</>
! and <filename>postmaster.opts</>, which record information
! about the running <application>postmaster</>, not about the
! <application>postmaster</> which will eventually use this backup.
! (These files can confuse <application>pg_ctl</>.)
</para>
<para>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
