On 3/3/15 5:13 PM, Tom Lane wrote:
Jim Nasby <jim.na...@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 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
