MIME-Version: 1.0
References: <3ydjipcr7kbss57nvi67noplncqhesl5eyb6wgol4ccjxynspv@yatlykpribmm>
 <DIM49A100EY1.2YFS2A6WAI3ZJ@jeltef.nl>
 <CAN55FZ30Np67cATsqYxF1SsP598VoRv4hJQZ4w9RA3Qe55prnQ@mail.gmail.com>
 <CAN55FZ13uX0cLSbgtSnnFeh5sTLeMr7+8UzmqpU6QjOtrRJTLg@mail.gmail.com>
 <qe4lh2i5di2gh7bxkbfisifaohrvyfukbybwxwzxdnll45hnt3@luod7i2mon67>
In-Reply-To: <qe4lh2i5di2gh7bxkbfisifaohrvyfukbybwxwzxdnll45hnt3@luod7i2mon67>
From: Jelte Fennema-Nio <postgres@jeltef.nl>
Date: Wed, 27 May 2026 22:33:30 +0200
Message-ID: 
 <CAGECzQQBCF=HSk4eCc1fEYTpCt59rgpcwWp47+6M-CDMYEaM2A@mail.gmail.com>
Subject: Re: Heads Up: cirrus-ci is shutting down June 1st
To: Andres Freund <andres@anarazel.de>
Cc: Nazir Bilal Yavuz <byavuz81@gmail.com>,
 Thomas Munro <thomas.munro@gmail.com>,
	pgsql-hackers@postgresql.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAGECzQQBCF%3DHSk4eCc1fEYTpCt59rgpcwWp47%2B6M-CDMYEaM2A%40mail.gmail.com>
Precedence: bulk

I didn't look at the patch, and I won't be able too before June 1st.
But I wanted to give some quick context on the things andres called
out, that I'm pretty sure originate from the patch I submitted.

On Wed, 27 May 2026 at 20:10, Andres Freund <andres@anarazel.de> wrote:
> > +# NB: intentionally NO workflow-level `concurrency:` block. The native
> > +# concurrency mechanism makes a new run wait for the previous one to f=
ully
> > +# cancel before it starts =E2=80=94 which can take a while. Instead th=
e
> > +# `cancel-previous` job below fires a cancel API call asynchronously,
> > +# so the new run gets going immediately. On master the cancel job is s=
kipped,
> > +# so every push runs to completion.
>
> Is this really worth having our own code? Seems like it'd not be that fre=
quent
> to push if there are already running runs?  What kind of delays are we ta=
lking
> about?

I agree this doesn't pull its weight and can be removed. It was part
of me trying to iterate quickly. I think it could take a few minutes
to cancel some of the jobs BSD nested virtualized jobs (might have
been other jobs though).

> I wonder if we should split the meson task into two, one for 32bit and on=
e for
> 64bit.

+1

> > +      # Install dependencies via Homebrew rather than Macports. On sto=
ck
> > +      # GH runners macports requires a heavy bootstrap, and the releva=
nt
> > +      # Postgres deps are all available in brew.
>
> What does "heavy bootstrap" mean?

Not sure. This was Claude's doing. MacOS was green pretty quickly, so
I didn't bother questioning details while all the other builds were
still red.

> We do spend ~95s on this every run, that's not nothing. And it puts a bun=
ch of
> load onto the brew's mirrors to do that every run.

I think we can only avoid that if we have our own runners.

> > +      # The TAP tests build an initdb template under build/tmp_install=
 and
> > +      # then `robocopy` it into per-test data directories. Robocopy wi=
th the
> > +      # default /COPY:DAT flag doesn't copy ACLs =E2=80=94 destination=
s inherit from
> > +      # their parent dir. On GitHub-hosted Windows runners the workspa=
ce's
> > +      # inherited ACL grants Administrators:(F) and Users:(RX) but doe=
s NOT
> > +      # grant the runner user (runneradmin) directly. That matters bec=
ause
> > +      # pg_ctl on Windows uses CreateRestrictedProcess to drop admin
> > +      # privileges from postmaster, so the postmaster process has the =
user
> > +      # SID in its token but no longer the Administrators group =E2=80=
=94 leaving it
> > +      # with only "Users:(RX)" on pg_control and friends, which causes
> > +      # "PANIC: could not open file global/pg_control: Permission deni=
ed".
> > +      #
> > +      # Fix it once on the workspace dir with (OI)(CI) inheritance fla=
gs so
> > +      # every file/dir created underneath gets an explicit grant for t=
he
> > +      # current user.
> > +      - name: Grant workspace ACL to runner user
> > +        shell: pwsh
> > +        run: |
> > +          icacls "${{ github.workspace }}" /grant "${env:USERNAME}:(OI=
)(CI)F" /Q | Out-Null
> > +          Write-Host "Granted Full Control to $env:USERNAME on ${{ git=
hub.workspace }}"
>
> Perhaps this would be better to fix by changing the robocopy flags?

Getting the Windows build working took a lot of work. To be clear that
involved me copy-pasting log output into Claude or pointing it to
download log tarballs. All of these huge comments I *did not* write.
While iterating the comments seemed believable (but LLMs are good at
that). My intent was to review them for correctness and for cleaner
solutions. But I did not have time nor energy for that anymore. So
yeah other fixes might very well be better (similarly for the
python3 or openssl stuff).