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

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Daniel Gustafsson <daniel@yesql.se>
Cc: Andres Freund <andres@anarazel.de>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>, Thomas Munro <thomas.munro@gmail.com>, Justin Pryzby <pryzby@telsasoft.com>, Nazir Bilal Yavuz <byavuz81@gmail.com>
Date: 2023-08-23T21:02:51Z
Lists: pgsql-hackers
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.

			regards, tom lane



Commits

  1. Use snprintf instead of sprintf in pg_regress.

  2. Speed up pg_regress server readiness testing.

  3. ci: Make compute resources for CI configurable

  4. ci: Prepare to make compute resources for CI configurable

  5. ci: Use VMs for SanityCheck and CompilerWarnings

  6. ci: Move execution method of tasks into yaml templates

  7. ci: Don't specify amount of memory

  8. ci: macos: Remove use of -Dsegsize_blocks=6

  9. ci: macos: Remove use of -DRANDOMIZE_ALLOCATED_MEMORY