←back to thread

When Sigterm Does Nothing: A Postgres Mystery

(clickhouse.com)
115 points saisrirampur | 1 comments | 15 Jul 25 04:43 UTC | HN request time: 0s | source
Show context
gsliepen ◴[15 Jul 25 07:39 UTC] No.44568872[source]▶

  pg_usleep(1000L);
Virtually any time you put a fixed sleep in your program, it's going to be wrong. It is either too long or too short, and even if it is perfect, there is no guarantee your program will actually sleep for exactly the requested amount of time. A condition variable or something similar would be the right thing to use here.

Of course, if this code path really is only taken very infrequently, you can get away with it. But assumptions are not always right, it's better to make the code robust in all cases.

replies(4): >>44569067 #>>44570238 #>>44571006 #>>44571476 #
1. anarazel ◴[15 Jul 25 11:59 UTC] No.44570238[source]▶
The usleep here isn't one that was intended to be taken frequently (and it's taken in a loop, so a too short sleep is ok). As it was introduced, it was intended to address a very short race that would have been very expensive to avoid altogether. Most of the waiting is intended to be done by waiting for a "transaction lock".

Unfortunately somebody decided that transaction locks don't need to be maintained when running as a hot standby. Which turns that code into a loop around the usleep...

(I do agree that sleep loops suck and almost always are a bad idea)