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

From: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Greg Stark <stark(at)mit(dot)edu>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Idea: closing the loop for "pg_ctl reload"
Date: 2015-03-03 22:57:58
Message-ID: 54F63C76.5030905@BlueTreble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 3/3/15 11:48 AM, Andres Freund wrote:
> On 2015-03-03 11:43:46 -0600, Jim Nasby wrote:
>> >It's certainly better than now, but why put DBAs through an extra step for
>> >no reason?
> Because it makes it more complicated than it already is? It's nontrivial
> to capture the output, escape it to somehow fit into a delimited field,
> et al. I'd rather have a committed improvement, than talks about a
> bigger one.

I don't see how this would be significantly more complex, but of course
that's subjective.

>> >Though, in the case of multiple errors perhaps it would be best
>> >to just report a count and point them at the log.
> 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? Either you'll get
the actual error message or a message that says "Didn't work, check the
log." And the error will always be in the log no matter what. I really
can't imagine that anyone would be unhappy that we just up-front told
them what the error was if we could. Why make them jump through needless
hoops?

> 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...
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2015-03-03 22:58:27 Re: Proposal: knowing detail of config files via SQL
Previous Message Greg Stark 2015-03-03 22:49:40 Re: Proposal: knowing detail of config files via SQL