Re: Why does analyze_new_cluster.sh use sleep?

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Why does analyze_new_cluster.sh use sleep?
Date: 2012-08-24 12:19:51
Message-ID: 20120824121951.GA23432@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Aug 23, 2012 at 11:15:06PM -0400, Peter Eisentraut wrote:
> On Thu, 2012-08-23 at 17:05 -0400, Bruce Momjian wrote:
> > On Thu, Aug 23, 2012 at 02:17:44AM -0400, Peter Eisentraut wrote:
> > > The script analyze_new_cluster.sh output by pg_upgrade contains several
> > > "sleep" calls (see contrib/pg_upgrade/check.c). What is the point of
> > > this? If the purpose of this script is to get the database operational
> > > again as soon as possible, waiting a few seconds doing nothing surely
> > > isn't helping.
> > >
> > > I could maybe see the point of waiting a bit between the different
> > > vacuumdb calls, to catch some breath, but the one before the first call
> > > to vacuumdb is highly dubious to me.
> >
> > The sleep is there so the user can read the status message, in case it
> > scrolls off the screen once the next stage starts.
>
> That seems completely arbitrary and contrary to the point of the script.
> The pg_upgrade output already explains what the script is for. If we
> really wanted the user to confirm what is going to happen, we should
> wait for a key press or something. I also don't think that 2 seconds is
> enough to read and react to the written text. Also, by that logic, we
> need to put a delay between each database processed by vacuumdb as well.

Well, the idea is that the script is running stages, and your system is
mostly useful after the first stage is done. I don't see a keypress as
helping there. I think this is different from the vacuumdb case.

--
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-hackers by date

  From Date Subject
Next Message Craig Ringer 2012-08-24 13:29:09 Re: Recently noticed documentation issues
Previous Message Magnus Hagander 2012-08-24 07:03:56 Re: 9.2RC1 wraps this Thursday ...