15.02.2017 0:06, I wrote:
[...]
> Indeed, such function is available. But essentially, this function is a
> (kind of) combined login+logout, therefore it would not work for my
> purpose. (Despite its name, it can not be used to perform some
> communication "ping" within an established session, such thing simply
> does not exist in the protocol, at least as of 9.5)
Ok, I've made some additions to the protocol to be able to do pings to a
real server, some standalone tests mimicing postgresql communication and
employing RDTSC, and run rediculously extensive experiments. And my
findings to the moment is that the reason for CPU load issue is a wierd
behaviour of windows' core functions, specifically
WaitForMultipleObjects (and apparently the whole family of Wait
functions) which is used in postgresql backend for waiting.
So, what I've observed is that Wait* functions _usually_ go to sleep
nicely when the state is not signalled, but _sometimes_, depending on
unknown criteria, it can choose to instead do a busy-loop wait or
something CPU-expensive. Maybe it tries to optimize the delay, or maybe
it is a bug. The effect somewhat varies depending on windows version,
CPU cores, selected system timer frequency, and Wait* call pattern
(frequency).
I can not currently see how it can be fixed in a generic and reliable
way in postgres without sacrificing some performance. On the other hand,
leaving it as-is is exposing the server to a substantial CPU abuse (even
unintentional, as it initially happened in my case).
Regards,
Nikolai
>
>
> Regards,
> Nikolai
>
>>
>> from mirror:
>> https://github.com/postgres/postgres/blob/master/src/bin/scripts/pg_isready.c
>>
>>
>> relevant call is PQping:
>>
>> rv = PQpingParams(keywords, values, 1);
>>
>>
>>
>
>
>