pg_ctl behavior on Windows
От | Chapman Flack |
---|---|
Тема | pg_ctl behavior on Windows |
Дата | |
Msg-id | 5F123C4B.3020509@anastigmatix.net обсуждение исходный текст |
Ответы |
Re: pg_ctl behavior on Windows
|
Список | pgsql-hackers |
Hi, So, I am not a Windows native, and here I am mentoring a GSoC student setting up CI on multiple environments, including Windows. In my own development and testing, by habit I do everything from unprivileged accounts, just spinning up an instance in a temp location, running some tests, and shutting it down. So I rarely run into the "I refuse to run from a privileged account" check in postgres. So rarely that it tends to slip my mind. The popular hosted CI services, by contrast, tend to run one's test scripts from a privileged account, so the scripts can just blithely install packages, frob configurations, and so on, and it all just works, Except for just spinning up a one-off postgres instance; that runs afoul of the privilege check. One workaround, of course, is to just use the postgres instance officially supplied by the CI service, already started and listening on the standard port. Then, in fact, you /need/ to be running with privilege, so you can install into the standard locations, frob configs, restart it, etc. Another is for the testing script to use its admin powers to create a new user without admin powers, and switch to that identity for the rest of the show. If I understand correctly what I'm seeing in the pg_ctl source, that would be the sole other option on a non-Windows system; 'pg_ctl start' as root on non-Windows will simply refuse, the same way direct invocation of postgres would. On the other hand, it seems that pg_ctl start on Windows has another trick up its sleeve, and in about 180 lines of fussing with arcane Windows APIs, it can arrange to run under the current identity but with its administrator-ness removed and privileges capped. Which seems cool. But there's a NOTE! in the comment for CreateRestrictedProcess: "Job object will only work when running as a service, because it's automatically destroyed when pg_ctl exits." I haven't been able to find any documentation of what that really means in practical terms, or quite figure it out from the code. Does that mean 'pg_ctl start' won't really work after all from a privileged account, or will seem to work but something will go wrong after the server is ready and pg_ctl exits? Does it mean the tersely-documented 'register' operation must be used, and that's the only way to start from a privileged account? I don't have an especially easy way to experiment on Windows; I can push experiments to the CI service and wait a bit to see what they do, but I figured I'd ask here first. Regards, -Chap
В списке pgsql-hackers по дате отправления: