Re: [PATCH] Re: [BUGS] BUG #7815: Upgrading PostgreSQL from 9.1 to 9.2 with pg_upgrade/postgreql-setup fails - invalid status retrieve

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Pavel Raiskup <praiskup(at)redhat(dot)com>
Cc: tgl(at)sss(dot)pgh(dot)pa(dot)us, giomac(at)gmail(dot)com, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Re: [BUGS] BUG #7815: Upgrading PostgreSQL from 9.1 to 9.2 with pg_upgrade/postgreql-setup fails - invalid status retrieve
Date: 2013-08-12 20:44:12
Message-ID: 20130812204412.GF12510@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

On Mon, Aug 12, 2013 at 10:08:07PM +0200, Pavel Raiskup wrote:
> > The patch moves the atexit setting up, as you suggested, but only does
> > that when pg_ctl succeeds (we know we started the server),
>
> Yes, of course!
>
> > PG 9.1+ will allow pg_ctl -w start to succeed even if there are
> > permissions problems; earlier versions will not and will keep the
> > server running --- the user will have to stop the server after
> > pg_upgrade says it is running.
>
> This makes it a complex, really.. We may not easily make the
> stop_postmaster resistant to non-running server. Thus your solution must
> be good enough.

Well, stop_postmaster can run just fine with a stopped server, as we
allow the atexit() shutdown to ignore errors. The larger question is
whether we should ever stop a server we are not sure we started.

The existing pg_upgrade logic checks if the servers are running first
with start_postmaster(throw_error = false), so in our existing code, we
could probably unconditionally shutdown the server even with a pg_ctl
error when using throw_error = true, but pg_upgrade is complex so I am
hesitant to make such a bold change. Does anyone else have an opinion?

> > I am not going to backpatch this beyond 9.3 as it is risky code. I have
> > improved the comments in this area.
>
> Agree, it is OK for me — thanks for your work.

Sure. You gave me something to study today, and highlighted an area of
the code that was very unclear.

--
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

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2013-08-12 20:58:23 Re: [BUGS] BUG #8335: trim() un-document behaviour
Previous Message Bruce Momjian 2013-08-12 20:29:10 Re: [BUGS] BUG #8335: trim() un-document behaviour

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2013-08-12 20:58:23 Re: [BUGS] BUG #8335: trim() un-document behaviour
Previous Message tubadzin 2013-08-12 20:31:38 Modyfication Sort Merge Join Alghoritm