From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Daniel Gustafsson <daniel(at)yesql(dot)se>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, Nazir Bilal Yavuz <byavuz81(at)gmail(dot)com> |
Subject: | Re: Cirrus-ci is lowering free CI cycles - what to do with cfbot, etc? |
Date: | 2023-08-23 21:55:53 |
Message-ID: | 3565659.1692827753@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2023-08-23 17:02:51 -0400, Tom Lane wrote:
>> ... unless we hit problems with, say, a different default port number or
>> socket path compiled into one copy vs. the other? That seems like it's
>> probably a "so don't do that" case, though.
> If we were to find such a case, it seems we could just add whatever missing
> parameter to the connection string? I think we would likely already hit such
> problems though, the psql started by an installcheck pg_regress might use the
> system libpq, I think?
The trouble with that approach is that in "make installcheck", we
don't really want to assume we know what the installed libpq's default
connection parameters are. So we don't explicitly know where that
libpq will connect.
As I said, we might be able to start treating installed-libpq-not-
compatible-with-build as a "don't do it" case. Another idea is to try
to ensure that pg_regress uses the same libpq that the psql-under-test
does; but I'm not sure how to implement that.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2023-08-23 22:06:12 | Re: Cirrus-ci is lowering free CI cycles - what to do with cfbot, etc? |
Previous Message | Daniel Gustafsson | 2023-08-23 21:54:03 | Re: Fix error handling in be_tls_open_server() |