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

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>
Cc: 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-28 12:32:24
Message-ID: 43B6331A-1005-4804-8644-ED30A31839F9@yesql.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 23 Aug 2023, at 23:12, Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:
>
>> On 23 Aug 2023, at 23:02, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>
>> Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
>>> On 23 Aug 2023, at 21:22, Andres Freund <andres(at)anarazel(dot)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.

Attached is a patch with a quick PoC for using PQPing instead of using psql for
connection checks in pg_regress. In order to see performance it also includes
a diag output for "Time to first test" which contains all setup costs. This
might not make it into a commit but it was quite helpful in hacking so I left
it in for now.

The patch incorporates Andres' idea for finer granularity of checks by checking
TICKS times per second rather than once per second, it also shifts the
pg_usleep around to require just one ping in most cases compard to two today.

On my relatively tired laptop this speeds up pg_regress setup with 100+ms with
much bigger wins on Windows in the CI. While it does add a dependency on
libpq, I think it's a fairly decent price to pay for running tests faster.

--
Daniel Gustafsson

Attachment Content-Type Size
v1-0001-Speed-up-pg_regress-server-testing.patch application/octet-stream 10.2 KB
unknown_filename text/plain 1 byte

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2023-08-28 12:55:54 Re: cataloguing NOT NULL constraints
Previous Message Peter Eisentraut 2023-08-28 12:31:19 Re: abi-compliance-checker