Re: Idea: closing the loop for "pg_ctl reload"

On 3/3/15 5:13 PM, Tom Lane wrote:
> Jim Nasby <Jim.Nasby@BlueTreble.com> writes:
>> On 3/3/15 11:48 AM, Andres Freund wrote:
>>> It'll be confusing to have different interfaces in one/multiple error cases.
>
>> If we simply don't want the code complexity then fine, but I just don't
>> buy this argument. How could it possibly be confusing?
>
> What I'm concerned about is confusing the code.  There is a lot of stuff
> that looks at pidfiles and a lot of it is not very bright (note upthread
> argument about "cat" vs "head -1").  I don't want possibly localized
> (non-ASCII) text in there, especially when there's not going to be any
> sane way to know which encoding it's in.  And I definitely don't want
> multiline error messages in there.

Definitely no multi-line. If we keep that restriction, couldn't we just 
dedicate one entire line to the error message? ISTM that would be safe.

> It's possible we could dumb things down enough to meet these restrictions,
> but I'd really rather not go there at all.

IMHO the added DBA convenience would be worth it (assuming we can make 
it safe). I know I'd certainly appreciate it...

On 3/3/15 5:24 PM, Jan de Visser wrote:> On March 3, 2015 04:57:58 PM 
Jim Nasby wrote:>> On 3/3/15 11:48 AM, Andres Freund wrote:>>>   I'm saying that you'll need a way to notice that a
reloadwas 
 
processed>>   > or not. And that can't really be the message itself, there has to be>>   > some other field; like the
timestampTom proposes.>>>> Ahh, right. We should make sure we don't go brain-dead if the system>> clock moves
backwards.I assume we couldn't just fstat the file...>> The timestamp field is already there (in my patch). It gets
populated
 
when the> server starts and repopulated by SIGHUP_handler. It's the only timestamp> pg_ctl pays attention to.

What happens if someone does a reload sometime in the future (perhaps 
because they've messed with the system clock for test purposes). Do we 
still detect a new reload?
-- 
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com