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 <[email protected]> wrote: > > +# NB: intentionally NO workflow-level `concurrency:` block. The native > > +# concurrency mechanism makes a new run wait for the previous one to fully > > +# cancel before it starts — which can take a while. Instead the > > +# `cancel-previous` job below fires a cancel API call asynchronously, > > +# so the new run gets going immediately. On master the cancel job is > > skipped, > > +# so every push runs to completion. > > Is this really worth having our own code? Seems like it'd not be that frequent > to push if there are already running runs? What kind of delays are we talking > 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 one for > 64bit. +1 > > + # Install dependencies via Homebrew rather than Macports. On stock > > + # GH runners macports requires a heavy bootstrap, and the relevant > > + # 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 bunch 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 with > > the > > + # default /COPY:DAT flag doesn't copy ACLs — destinations inherit > > from > > + # their parent dir. On GitHub-hosted Windows runners the workspace's > > + # inherited ACL grants Administrators:(F) and Users:(RX) but does NOT > > + # grant the runner user (runneradmin) directly. That matters because > > + # 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 — leaving > > it > > + # with only "Users:(RX)" on pg_control and friends, which causes > > + # "PANIC: could not open file global/pg_control: Permission denied". > > + # > > + # Fix it once on the workspace dir with (OI)(CI) inheritance flags so > > + # every file/dir created underneath gets an explicit grant for the > > + # 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 ${{ > > github.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).
