Re: Regression tests failures on Windows Server 2019 - on master at commit # d816f366b

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Regression tests failures on Windows Server 2019 - on master at commit # d816f366b
Date: 2022-03-04 22:04:44
Message-ID: 20220304220444.fxmxsouunrypskwi@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2022-03-04 16:51:32 -0500, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2022-03-04 22:06:38 Re: Regression tests failures on Windows Server 2019 - on master at commit # d816f366b
Previous Message Melanie Plageman 2022-03-04 22:03:09 Re: Avoiding smgrimmedsync() during nbtree index builds