Re: Build failure with GCC 15 (defaults to -std=gnu23) - Mailing list pgsql-bugs

From Robins Tharakan
Subject Re: Build failure with GCC 15 (defaults to -std=gnu23)
Date
Msg-id CAEP4nAzNb=ikYY6k8a0V2XP-M-HXga6Wf2hVbr7JAY1Aots-1Q@mail.gmail.com
Whole thread Raw
In response to Re: Build failure with GCC 15 (defaults to -std=gnu23)  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: Build failure with GCC 15 (defaults to -std=gnu23)
List pgsql-bugs

On Sat, 14 Dec 2024 at 00:18, Andrew Dunstan <andrew@dunslane.net> wrote:

We actually have a good deal of protection against concurrent runs clobbering each other.

It's not clear to me if you're using "run_branches.pl --run-parallel" or not. If not, you might like to consider changing to that - it's the recommended way of doing concurrent runs. Apart from any other reason it removes the need for a lot of redundant git fetches. By default it staggers concurrent build starts by 60 seconds.


In this case I didn't use run_branches.pl. I just opened up two sessions and triggered two
separate runs for v16 / v17 (with --force) since master just came out green. Efficiency aside,
at worst I was expecting two concurrent runs to be slower, but not error out.

Unrelated, for a slow system my understanding was that it's quite inefficient to keep running older
branches every few minutes (like HEAD does) - so for some of the animals I explicitly run older
branches (for e.g. v13) every few hours, but HEAD runs every few minutes. 

Are you saying it's still a good idea to run all together every few minutes (and let older branches
skip if there's nothing to do)?

-
robins

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: "memory exhausted" in query parser/simplifier for many nested parentheses
Next
From: Tom Lane
Date:
Subject: Re: Build failure with GCC 15 (defaults to -std=gnu23)