Re: [PATCH] better systemd integration - Mailing list pgsql-hackers

From Christoph Berg
Subject Re: [PATCH] better systemd integration
Date
Msg-id 20160128144621.GD13097@msg.df7cb.de
Whole thread Raw
In response to Re: [PATCH] better systemd integration  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: [PATCH] better systemd integration  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
Hi Peter,

thanks for working on this, I'm looking forward to make Debian's
pg_*cluster tools work with that (and hopefully be able to remove tons
of legacy code).

If a cluster is configured for non-hot-standby replication, the
READY=1 seems to never happen. Did you check if that doesn't trigger
any timeouts with would make the unit "fail" or the like?

@@ -2787,6 +2800,10 @@ reaper(SIGNAL_ARGS)                       ereport(LOG,
(errmsg("databasesystem is ready to accept connections"))); 

+#ifdef USE_SYSTEMD
+                       sd_notify(0, "READY=1");
+#endif
+                       continue;               }

@@ -4930,6 +4947,10 @@ sigusr1_handler(SIGNAL_ARGS)               ereport(LOG,               (errmsg("database system
isready to accept read only connections"))); 

+#ifdef USE_SYSTEMD
+               sd_notify(0, "READY=1");
+#endif
+               pmState = PM_HOT_STANDBY;               /* Some workers may be scheduled to start now */
StartWorkerNeeded= true; 


Also, I'm wondering how hard it would be to get socket activation work
with that? (I wouldn't necessarily recommend that for production use,
but on my desktop it would certainly be helpful not to have all those
8.4/9.0/.../9.6 clusters running all the time doing nothing.)

Christoph
--
cb@df7cb.de | http://www.df7cb.de/

pgsql-hackers by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: New committer
Next
From: Vladimir Sitnikov
Date:
Subject: Re: Set search_path + server-prepared statements = cached plan must not change result type