Re: ECPG installcheck tests fail if PGDATABASE is set

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Michael Meskes <meskes(at)postgresql(dot)org>,pgsql-hackers(at)postgresql(dot)org
Subject: Re: ECPG installcheck tests fail if PGDATABASE is set
Date: 2018-03-18 23:09:58
Message-ID: 3818BA84-1748-4447-BDC4-7F5B4A11E0E1@anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On March 18, 2018 4:06:18 PM PDT, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>Andres Freund <andres(at)anarazel(dot)de> writes:
>> I got a bit confused running installcheck-world and seeing ecpg
>> failures like:
>> ...
>> A bit of pondering pointed me towards my environment's
>> PGDATABASE=postgres being to blame. Unsetting that makes the test
>> succeed.
>
>Hm ... pg_regress unsets PGDATABASE, along with the other related
>environment variables, when it has a temp installation but not
>when it doesn't. So what I don't understand is why your environment
>doesn't also break every other regression test besides ecpg.
>Perhaps they're all connecting to "postgres", but it's hard to
>believe there wouldn't be conflicts if so.

All the others specify a database. The issue with the ecpg test is that it doesn't for two test cases. The failure is caused by libpq guessing the db name from the user name (hence the error about a database with role in it), which doesn't happen if libpq sees the environment variable.

Andres
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Gustafsson 2018-03-18 23:28:05 Re: [HACKERS] AdvanceXLInsertBuffer vs. WAL segment compressibility
Previous Message Tom Lane 2018-03-18 23:06:18 Re: ECPG installcheck tests fail if PGDATABASE is set