Hello.
At Thu, 14 Mar 2019 09:42:44 +0000, "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com> wrote in
<0A3221C70F24FB45833433255569204D1FBC7626@G01JPEXMBYT05>
> From: MikalaiKeida@ibagroup.eu [mailto:MikalaiKeida@ibagroup.eu]
> > > For example, OS issues such as abnormally (buggy) slow process scheduling
> > or paging/swapping that prevent control from being passed to postgres. Or,
> > abnormally long waits on lwlocks in postgres. statement_timeout doesn't
> > take effect while waiting on a lwlock. I have experienced both. And, any
> > other issues in the server that we haven't experienced and not predictable.
> >
> > For me all mentioned by Takayuki Tsunakawa problems looks like a lack of
> > design of end-user application or configuration of DB server. It is not
> > a problem of PostgreSQL.
>
> Certainly, my cases could be avoided by the OS and database
> configuration. But we cannot say all such problems can be
> avoided by configuration in advance. The point is to provide a
> method to get ready for any situation.
Right. We can't perfectly predict in advance what happens on a
server and server cannot perfectly surmise in advance what every
client wants. Clients can avoid something by using something
that is not fully understood, that leads to another unpredictable
trouble. This is the reason how a feature works should be
understandable for users. I saw many cases where an HA cluster
fails over for mysterious reasons for users, who are considered
to understood them. (That happens more frequently on virtual
machines.) If the application should return a response in, say,
10 seconds, the application should do that by itself.
# I hope it is comprehensible..
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
