Group cluster_name and update_process_title settings together

[postgresql] / src / port / pgsleep.c

diff --git a/src/port/pgsleep.c b/src/port/pgsleep.c
index 884e257dd7ad3395657b48d07c8232922239f196..89a12b9da7c451e25053f6fc818844eede8b5a34 100644 (file)
--- a/src/port/pgsleep.c
+++ b/src/port/pgsleep.c
@@ -4,9 +4,9 @@
  *        Portable delay handling.
  *
  *
- * Portions Copyright (c) 1996-2010, PostgreSQL Global Development Group
+ * Portions Copyright (c) 1996-2015, PostgreSQL Global Development Group
  *
- * $PostgreSQL: pgsql/src/port/pgsleep.c,v 1.13 2010/01/02 16:58:13 momjian Exp $
+ * src/port/pgsleep.c
  *
  *-------------------------------------------------------------------------
  */
@@ -29,6 +29,16 @@
  * the requested delay to be rounded up to the next resolution boundary.
  *
  * On machines where "long" is 32 bits, the maximum delay is ~2000 seconds.
+ *
+ * CAUTION: the behavior when a signal arrives during the sleep is platform
+ * dependent.  On most Unix-ish platforms, a signal does not terminate the
+ * sleep; but on some, it will (the Windows implementation also allows signals
+ * to terminate pg_usleep).  And there are platforms where not only does a
+ * signal not terminate the sleep, but it actually resets the timeout counter
+ * so that the sleep effectively starts over!  It is therefore rather hazardous
+ * to use this for long sleeps; a continuing stream of signal events could
+ * prevent the sleep from ever terminating.  Better practice for long sleeps
+ * is to use WaitLatch() with a timeout.
  */
 void
 pg_usleep(long microsec)