pg_ctl behavior on Windows

Поиск
Список
Период
Сортировка
От Chapman Flack
Тема pg_ctl behavior on Windows
Дата
Msg-id 5F123C4B.3020509@anastigmatix.net
обсуждение исходный текст
Ответы Re: pg_ctl behavior on Windows  (Amit Kapila <amit.kapila16@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Justin Pryzby
Дата:
Сообщение: Re: expose parallel leader in CSV and log_line_prefix
Следующее
От: Jeff Davis
Дата:
Сообщение: Re: Default setting for enable_hashagg_disk