Re: [GENERAL] Schedule - Mailing list pgsql-general

On 06/20/2017 01:23 PM, Alban Hertroys wrote:
>
>> On 20 Jun 2017, at 18:46, Adrian Klaver <adrian.klaver@aklaver.com> wrote:

>>
>> Yes this could be become complicated if for no other reason then it is being driven from the customer end and there
willneed to be a process to verify and incorporate their changes. 
>
> There you're saying something rather important: "If it is being driven from the customer end".

Yeah, it is the interaction between technical issues and people issues.
One is easier to solve then the other:)

>
>> 2) Figure out what a day is. In other words are different timezones involved and if so what do you 'anchor' a day
to?
>
> For an example of how that might fail: At our company, they work in shifts (I don't) of 3*8 hours, that run from
23:00to 23:00. Depending on who looks at the data, either that's a day or a normal day (00:00-00:00) is. It's a matter
ofperspective. 

I see that as part of how to 'anchor' a day. Right now Steve is looking
at one customer as I understand it. I would expect that might change so
I can envision a system that would need to account for different
definitions of a day. Still you have to start somewhere.

>
>
> IMHO, the only safe approach is to have the customer end decide whether it's a regular outage or an irregular one.
Thereis just no way to reliably guess that from the data. If a customer decides to turn off the system when he's going
home,you can't guess when he's going to do that and you will be raising false positives when you depend on a schedule
ofwhen he might be going home. 
>
>  From a software implementation point of view that means that your customer-side application needs to be able to
signalplanned shutdowns and startups. If you detect any outages without such a signal, then you can flag it as a
problem.

I agree. I personally see false alerts as a form of 'Crying wolf' and I
think that down the road they lead to complacency. Hence my earlier
suggestion to have a method to indicate manual intervention on the
customer end.

>
> There are still opportunities for getting those wrong of course, such as lack of connectivity between you and your
customer,but those should be easy to explain once detected. 
> And I'm sure there are plenty of other corner-cases you need to take into account. I bet it has a lot of problems in
commonwith replication actually (how do we reliably get information from system A to system B), so it probably pays to
lookat what particular problems occur there and how they're solved. 

I would say a good deal of the above is going to be driven by legal
considerations. Who is responsible for what and what guarantees are in
effect.

>
> Alban Hertroys


--
Adrian Klaver
adrian.klaver@aklaver.com