From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | 0010203112132233 <boekewurm(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net> |
Subject: | Re: Adding CI to our tree |
Date: | 2021-10-02 19:59:09 |
Message-ID: | 20211002195909.7bt7btp4pjycpvcc@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2021-10-02 11:05:20 -0400, Tom Lane wrote:
> Yeah. I cannot see any reason to object to Andres' 0002 patch: you can
> just ignore those files if you don't want to use cirrus. It does set a
> precedent that we'd also accept infrastructure for other CI systems,
> but as long as they're similarly noninvasive, why not?
Exactly.
> (Maybe there needs to be one more directory level though, ie
> ci/cirrus/whatever. I don't want to end up with one toplevel directory per
> CI platform.)
Good question - it definitely shouldn't be one toplevel directory per CI
platform (although some will require their own hidden toplevel directories,
like .github/workflows etc). I'd hope to share a bunch of the infrastructure
between them over time, so perhaps we don't need a deeper hierarchy.
> I don't know enough about Windows to evaluate 0001, but I'm a little
> worried about it because it looks like it's changing our *production*
> error handling on that platform.
Yea. It's clearly not ready as-is - it's the piece that I was planning to
write a separate email about.
It's hard to understand what *precisely* SEM_NOGPFAULTERRORBOX etc do.
What I do know is that without the _set_abort_behavior() stuff abort() doesn't
trigger windows' "crash" paths in at least debugging builds, and that the
SetErrorMode() and _CrtSetReportMode() changes are necessary to get segfaults
to reach the crash paths.
The in-tree behaviour turns out to make debugging on windows a major pain, at
least when compiling with msvc. Crashes never trigger core dumps or "just in
time" debugging (their term for invoking a debugger upon crash), so one has to
attach to processes before they crash, to have any chance of debugging.
As far as I can tell this also means that at least for debugging builds,
pgwin32_install_crashdump_handler() is pretty much dead weight -
crashDumpHandler() never gets invoked. I think it may get invoked for abort()s
in production builds, but probably not for segfaults.
And despite SEM_NOGPFAULTERRORBOX we display those annoying "popup" boxes
telling us about the crash and giving the option to retry, ignore, something
something. It's all a bit baffling.
> As for 0003, wasn't that committed already?
Not at the time I was writing the email, but now it is, yes.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2021-10-02 20:01:51 | Re: Adding CI to our tree |
Previous Message | Daniel Gustafsson | 2021-10-02 19:49:30 | Re: Adding CI to our tree |