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.
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 |