Re: Cirrus-ci is lowering free CI cycles - what to do with cfbot, etc? - Mailing list pgsql-hackers

From Daniel Gustafsson
Subject Re: Cirrus-ci is lowering free CI cycles - what to do with cfbot, etc?
Date
Msg-id B0CDD2D6-DBCF-4E8B-8322-4B1D7ED50DCA@yesql.se
Whole thread Raw
In response to Re: Cirrus-ci is lowering free CI cycles - what to do with cfbot, etc?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Cirrus-ci is lowering free CI cycles - what to do with cfbot, etc?
List pgsql-hackers
> On 23 Aug 2023, at 23:02, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Daniel Gustafsson <daniel@yesql.se> writes:
>> On 23 Aug 2023, at 21:22, Andres Freund <andres@anarazel.de> wrote:
>>> I think there's more effective ways to make this cheaper. The basic thing
>>> would be to use libpq instead of forking of psql to make a connection
>>> check.
>
>> I had it in my head that not using libpq in pg_regress was a deliberate choice,
>> but I fail to find a reference to it in the archives.
>
> I have a vague feeling that you are right about that.  Perhaps the
> concern was that under "make installcheck", pg_regress might be
> using a build-tree copy of libpq rather than the one from the
> system under test.  As long as we're just trying to ping the server,
> that shouldn't matter too much I think ... 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.

Ah yes, that does ring a familiar bell.  I agree that using it for pinging the
server should be safe either way, but we should document the use-with-caution
in pg_regress.c if/when we go down that path.  I'll take a stab at changing the
psql retry loop for pinging tomorrow to see what it would look like.

--
Daniel Gustafsson




pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: PostgreSQL 16 release announcement draft
Next
From: Andres Freund
Date:
Subject: Re: Cirrus-ci is lowering free CI cycles - what to do with cfbot, etc?