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

On 3/3/15 5:13 PM, Tom Lane wrote:
> Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)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 reload was
processed
>> > or not. And that can't really be the message itself, there has to be
>> > some other field; like the timestamp Tom 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