Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eJm0q-0006bZ-EN for pgsql-hackers@arkaria.postgresql.org; Tue, 28 Nov 2017 19:57:48 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eJm0p-0004EI-Rk for pgsql-hackers@arkaria.postgresql.org; Tue, 28 Nov 2017 19:57:47 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1eJm0p-0004E7-Ff for pgsql-hackers@lists.postgresql.org; Tue, 28 Nov 2017 19:57:47 +0000 Received: from mail-pl0-x234.google.com ([2607:f8b0:400e:c01::234]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1eJm0m-0004qv-OO for pgsql-hackers@postgresql.org; Tue, 28 Nov 2017 19:57:45 +0000 Received: by mail-pl0-x234.google.com with SMTP id f6so566831pln.12 for ; Tue, 28 Nov 2017 11:57:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VdQIrWt8wTRBnOmWSwrPJ1Vfl2dOXvF9VvPgc9bxmMU=; b=Nuv6yL/q+Vwo+uZ4hZsseaWpBt8pczrdAO8rzaymEOtbD0RjQoO5j2JpnXpOwWKU6t 8G426nOSPPWl/H2xAzUEEXtRFPMbvvohNFjMYOXU1OGCwR2st61XGY9RTuqBBAXLBJDL DmLcseTpBZg9vqVujXfOmMpYfchTV+/XT46YiPvMRKzDkEal2Egv6CrXk7p4dh/8CBRj Di1DFHjXj/Pq0Iyrj3usZlT4KazQYRRSPLYKafwr1phCewCqHKuhlUQJDISYSxsI9TGM XWXR9iPIfFTsEkTkBA23TUtKK5ne7gtY7BzrFlhP+Ve5ihZFU7kB4pqxDZT57eg3jMI2 YlEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VdQIrWt8wTRBnOmWSwrPJ1Vfl2dOXvF9VvPgc9bxmMU=; b=I/vJ/PBI03LWTkeP7T2JqxOhiU4DNGd4AWvxeLojMUywwyzaAsHjJKop0/EyiMNGhv 5BFJoMzEv6OF2NUgnT8azBAyh9DcKfdUUvftNqNq5zmxRfjiJ+hQr2OcvsRa+G8G0e0J k1YRo5PToCq3xJvq9h4cB7YXIGr3HT74kX2EXijyQuqJLMZX1V86dpxUemLVQ1S4yI7X LKaxSbmkW6ARDp0gAqU/uarmH6z9uQba4PyfchZbyVgB0gtaCFMBirFh+P11GQAKWeIj ZWA53wQ5WZgwjF1skbpUPjmtZQkj4BybKnzm0AQpZUdXT0LiK27stgA3fVaNaX15HXbn a0Kw== X-Gm-Message-State: AJaThX4UIXTNvn40XtCs8mmSlpkXOLMMdlnGxB4rbqV/HV2W+D3x924K 1u+QJJ2l6OJXp+Hv2GdsEEQ= X-Google-Smtp-Source: AGs4zMbgbiyMSC5r6hokiFxc86/X29AxN4Fu3XeVhpXbjKNHBxKnWddFRPxXHbH58tOBNiQWOJjHCA== X-Received: by 10.84.202.194 with SMTP id q2mr307025plh.19.1511899063329; Tue, 28 Nov 2017 11:57:43 -0800 (PST) Received: from [192.168.2.121] ([172.92.45.130]) by smtp.gmail.com with ESMTPSA id y5sm58629428pfa.128.2017.11.28.11.57.42 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 28 Nov 2017 11:57:42 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Updated macOS start scripts From: Mark Dilger In-Reply-To: <3786.1511896652@sss.pgh.pa.us> Date: Tue, 28 Nov 2017 11:57:41 -0800 Cc: pgsql-hackers@postgreSQL.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <31338.1510763554@sss.pgh.pa.us> <6D443E39-13C2-4185-9FE4-B5CB416AB06E@gmail.com> <21689.1510772433@sss.pgh.pa.us> <173420E2-64DB-4802-9EB2-AEFB11F46045@gmail.com> <3786.1511896652@sss.pgh.pa.us> To: Tom Lane X-Mailer: Apple Mail (2.3124) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk > On Nov 28, 2017, at 11:17 AM, Tom Lane wrote: >=20 > Mark Dilger writes: >> Upon further review, I have noticed that `pg_ctl stop` does not work = once >> the org.postgresql.postgres service has been started. I was trying = to stop, >> reinstall and re-initdb and restart postgres and this service was a = pita. I had >> to go back to your osx.patch to remind myself what I had done and = only then >> could I stop the service and continue my work. >=20 >> Is there any way this patch could be improved to work nicely with = pg_ctl? It >> seems that `pg_ctl stop` indeed stops the postgres process, but the = system >> launches a new one so quickly that pg_ctl thinks the service has not = stopped, >> and it just waits forever (or until it times out, depending on your = settings). >=20 > Hmm. Maybe we should have the plist file set KeepAlive to false not = true? > This would mean you'd need manual action to restart a failed = postmaster, > but that probably comes with the territory --- I do not see how we'd > teach launchd the difference between a "failed" postmaster and a = manually > shut down one. Setting KeepAlive to false does more than you probably want it to; it = also causes the service not to start on boot nor on load. After setting this = to false, I tried a reboot and the service was not started. >=20 > I think the normal way to stop/restart a launchd service is to use > "launchctl unload/load" ... we'd need to see how that interacts with > using pg_ctl. Some documentation might be needed in any case. "launchctl load" won't do it. You need to use sudo launchctl start org.postgresql.postgres and sudo launchctl stop org.postgresql.postgres to get the behavior you are looking for. Note that start/stop take the = name of the service, and load/unload take the name of the file. They're = different, though related. I think anybody who uses launchctl on mac should already know what it = does. I'm not too concerned about that. I think the hazard is that somebody = who does not normally use launchctl on mac, but who reads through the postgres contrib/start-scripts directory, will follow the instructions in this = patch and form a false expectation about what will result from configuring their = mac laptop this way. Of course, you could make pg_ctl know how to interact with launchctl if = you like. That seems quite hard, and I am not volunteering.... mark