Re: 8.04 and RedHat/CentOS init script issue

Hi,

On Tue, 18 Oct 2005, Tony Caduto wrote:

> I installed 8.04 via RPM on Centos 4.2 which is the same as RedHat 4.2 and
> while booting the init script reports that the daemon [FAILED], but after I
> logon it shows the postmaster running and I am able to connect from any
> client remotely.
>
> I made not modifcations to the script and there is nothing out of the
> ordinary in the log.

Hmm. In 8.0.4 RPM init scripts, we were using a 1 second of sleep time
(see sleep 1 line in the init script). On some cases where the system is
slow, you are prompted about the startup failure; however this is not the
real case.

In 8.1 RPMs, the sleep time was increased to 2 seconds; which we believe
that won't have the problem you've reported:

http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgsqlrpms/patches/8.1/postgresql.init?rev=1.2&content-type=text/x-cvsweb-markup

So please increase this sleep time and give another try.

Regards,
--
Devrim GUNDUZ
Kivi Bilişim Teknolojileri - http://www.kivi.com.tr
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org
>From pgsql-hackers-owner(at)postgresql(dot)org Wed Oct 19 14:43:36 2005
X-Original-To: pgsql-hackers-postgresql(dot)org(at)localhost(dot)postgresql(dot)org
Received: from localhost (av.hub.org [200.46.204.144])
by svr1.postgresql.org (Postfix) with ESMTP id 3CBA6D89FB
for <pgsql-hackers-postgresql(dot)org(at)localhost(dot)postgresql(dot)org>; Wed, 19 Oct 2005 14:43:35 -0300 (ADT)
Received: from svr1.postgresql.org ([200.46.204.71])
by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
with ESMTP id 75948-05
for <pgsql-hackers-postgresql(dot)org(at)localhost(dot)postgresql(dot)org>;
Wed, 19 Oct 2005 17:43:32 +0000 (GMT)
Received: from gwmta.wicourts.gov (gwmta.wicourts.gov [165.219.244.99])
by svr1.postgresql.org (Postfix) with ESMTP id D6122D6DAA
for <pgsql-hackers(at)postgresql(dot)org>; Wed, 19 Oct 2005 14:43:32 -0300 (ADT)
Received: from Courts-MTA by gwmta.wicourts.gov
with Novell_GroupWise; Wed, 19 Oct 2005 12:43:33 -0500
Message-Id: <43563F65020000250000012B(at)gwmta(dot)wicourts(dot)gov>
X-Mailer: Novell GroupWise Internet Agent 7.0
Date: Wed, 19 Oct 2005 12:43:17 -0500
From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: A costing analysis tool
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new at hub.org
X-Spam-Status: No, hits=0.003 required=5 tests=[AWL=0.003]
X-Spam-Level:
X-Archive-Number: 200510/822
X-Sequence-Number: 74681

Summary of schema I'm considering. Comments welcome.

When it gets downt to the detail, it may make sense to combine
or split some of these. For example, runtime_options should
probably not have a column for each currently known option,
but a child table which maps to all non-default option values.

submitter
Identifies who submitted test results.
Name, optional info such as email address and organization

runtime_environment
Identifies the overall test environment.
OS with distribution & version, CPU number, type speed, RAM,
background load, static configuration, etc.
This provides context for a series of tests, to see how the numbers
look in a given environment

dataset_characteristics
Identifies data metrics which may affect costing accuracy
Table counts, row counts, column counts, disk space used,
level of fragmentation.
Maybe some of the "standard" tests will share common dataset
characteristics across multiple environments.

cache_state
Identifies the level of initial caching for a test, and the degree to
which
the referenced data can be cached during execution

runtime_options
Identifies the runtime choices in effect for a query run.
The state of EXPLAIN, ANALYZE, enable_xxx, and dynamic configuration
settings, such as random_page_cost.

query
Identifies a test query, possibly run by many people in many
environments
against various datasets with different cache states and runtime
options

test_result_summary
Ties a query to details about a run, with a summary of results.
Run time from the client perspective, rows returned.

test_result_step_detail
Shows EXPLAIN ANALYZE information (if any) for each step.