On Fri, Oct 16, 2020 at 04:56:47PM -0400, Tom Lane wrote: > Bruce Momjian <br...@momjian.us> writes: > > Second, in testing starting/stopping the server, pg_ctl doesn't allow > > the cluster_passphrase_command to read from /dev/tty, which I think is a > > requirement because the command could likely require a user-supplied > > unlock key, even if that is not the actual passphrase, just like ssl > > keys. This is because pg_ctl calls setsid() just before calling execl() > > to start the server, and setsid() disassociates itself from the > > controlling terminal. I think the fix is to remove setsid() from pg_ctl > > and add a postmaster flag to call setsid() after it has potentially > > called cluster_passphrase_command, and pg_ctl would use that flag. > > We discussed that and rejected it in the thread leading up to > bb24439ce [1]. The primary problem being that it's not very clear > when the postmaster should daemonize itself, and later generally > isn't better. I doubt that this proposal is doing anything to > clarify that situation.
Agreed. No reason to destablize the postmaster for this. What about having pg_ctl open /dev/tty, and then pass in an open file descriptor that is a copy of /dev/tty, that can be closed by the postmaster after the cluster_passphrase_command? I just tested this and it worked. I am thinking we would pass the file descriptor number to the postmaster via a command-line argument. Ideally we would pass in the device name of /dev/tty, but I don't know of a good way to do that. -- Bruce Momjian <br...@momjian.us> https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee
