Re: [PATCHES] odd output in restore mode - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: [PATCHES] odd output in restore mode
Date
Msg-id 1217671669.3934.119.camel@ebony.t-mobile.de.
Whole thread Raw
In response to Re: [PATCHES] odd output in restore mode  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PATCHES] odd output in restore mode
List pgsql-hackers
On Thu, 2008-07-31 at 12:32 -0400, Tom Lane wrote:
> "Heikki Linnakangas" <heikki@enterprisedb.com> writes:
> > Martin Zaun wrote:
> >> With these avenues to be explored, can the pg_standby patch on the
> >> CommitFest wiki be moved to the "Returned with Feedback" section?
>
> > Yes, I think we can conclude that we don't want this patch as it is.
> > Instead, we want a documentation patch that describes the problem,
> > mentioning that GNU cp is safe, or you can use the copy+rename trick.
>
> Right, after which we remove the presently hacked-in delay.
>
> I've updated the commitfest page accordingly.

Well, this is a strange conclusion, leaving me slightly bemused.

The discussion between Andrew and I at PGcon concluded that we would
* document which other tools to use
* remove the delay

Now we have rejected the patch which does that, but then re-requested
the exact same thing again.

The patch interprets "remove the delay" as "remove the delay in a way
which will not screw up existing users of pg_standby when they upgrade".
Doing that requires us to have a configurable delay, which defaults to
the current behaviour, but that can be set to zero (the recommended
way). Which is what the patch implements.

Andrew, Heikki: ISTM its time to just make the changes yourselves. This
is just going round and round to no benefit. This doesn't warrant such a
long discussion and review process.

--
 Simon Riggs           www.2ndQuadrant.com
 PostgreSQL Training, Services and Support


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Should creating a new base type require superuser status?
Next
From: Magnus Hagander
Date:
Subject: Parsing of pg_hba.conf and authentication inconsistencies