To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Jeff Frost <jeff@frostconsultingllc.com>,
	Richard Huxton <dev@archonet.com>, pgsql-docs@postgresql.org
Subject: Re: Proposed doc-patch: Identifying the Current WAL file 
In-reply-to: <200604151809.k3FI96M06462@candle.pha.pa.us> 
References: <200604151809.k3FI96M06462@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
	message dated "Sat, 15 Apr 2006 14:09:06 -0400"
Date: Sat, 15 Apr 2006 14:50:05 -0400
Message-ID: <20681.1145127005@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Bruce Momjian <pgman@candle.pha.pa.us> writes:
> The point is that the test does not have a
> one-second window of showing the wrong answer, meaning I could wait for
> 60 seconds, and still see the wrong WAL file at the top.

Oh, I see your point: you can lose at most one second's worth of data,
but that second could be arbitrarily long ago if it was the latest
activity in the database.  Yeah, that's a bit unpleasant.  So we really
do need both parts of the ordering rule, and there seems no way to do
that with just 'ls'.

I wonder if you could do anything with find(1)'s -newer switch?
It seems to be a '>' condition not a '>=' condition, so it'd be
pretty awkward ... certainly not a one-liner.

I think everyone agrees that adding a SQL function would be a reasonable
thing to do, anyway.

			regards, tom lane