Re: Regression tests failures on Windows Server 2019 - on master at commit # d816f366b
От | Andres Freund |
---|---|
Тема | Re: Regression tests failures on Windows Server 2019 - on master at commit # d816f366b |
Дата | |
Msg-id | 20220304220444.fxmxsouunrypskwi@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Regression tests failures on Windows Server 2019 - on master at commit # d816f366b (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Regression tests failures on Windows Server 2019 - on master at commit # d816f366b
Re: Regression tests failures on Windows Server 2019 - on master at commit # d816f366b |
Список | pgsql-hackers |
Hi, On 2022-03-04 16:51:32 -0500, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: > > That fixed the immediate problem, but dblink, postgres_fdw tests failed: > > +ERROR: could not establish connection > > +DETAIL: connection to server at "localhost" (::1), port 5432 failed: FATAL: > > role "SYSTEM" does not exist > > [ scratches head... ] Where is libpq getting that username from? > Why is it different from whatever we'd determined during initdb? > (Maybe a case-folding issue??) When running as a service (via pg_ctl register) the default username to run under appears to be SYSTEM. Which then differs from the user that vcregress.pl runs under. Trying to make it use the current user now - I don't know what permissions services are needed to run a service as a user or such. > > The dblink and fdw failures can presumably be fixed by passing current_user as > > the username. That seems like a good idea anyway? > > I don't think it's a good idea to hack that without understanding > why it's suddenly going wrong. I think I understand why - seems more a question of whether we want to support running tests against a server running as a different user. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: