I've now committed all of this. I ended up finding a couple other frontend
programs that called pqsignal() with an invalid signal number on Windows,
so I fixed those as well. AFAICT the reason I didn't catch them in my
earlier testing is because they aren't tested! I'll keep an eye on the
buildf
On Thu, Jan 16, 2025 at 12:47 PM Nathan Bossart
wrote:
> On Thu, Jan 16, 2025 at 11:07:41AM +1300, Thomas Munro wrote:
> > +1 for your idea of not defining them at all outside the backend, it's
> > just confusing noise.
>
> I tried that, but these extra signals are needed even in the frontend for
4f Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Wed, 15 Jan 2025 17:30:23 -0600
Subject: [PATCH v4 1/2] Convert libpgport's pqsignal() to a void function.
The protections added by commit 3b00fdba9f introduced race
conditions to this function that can lead to bogus return values.
Since
On Thu, Jan 16, 2025 at 8:47 AM Nathan Bossart wrote:
> On Thu, Jan 16, 2025 at 08:21:08AM +1300, Thomas Munro wrote:
> > Could be due to calling native signal() with a signal number other
> > than the 6 values required to work by the C standard?
>
> Looking closer, that probably makes more sense
On Wed, Jan 15, 2025 at 01:47:18PM -0600, Nathan Bossart wrote:
> On Thu, Jan 16, 2025 at 08:21:08AM +1300, Thomas Munro wrote:
>> Could be due to calling native signal() with a signal number other
>> than the 6 values required to work by the C standard?
>
> Looking closer, that probably makes mor
On Thu, Jan 16, 2025 at 08:21:08AM +1300, Thomas Munro wrote:
> On Thu, Jan 16, 2025 at 8:15 AM Nathan Bossart
> wrote:
>> On Tue, Jan 14, 2025 at 11:08:05PM -0500, Tom Lane wrote:
>> > I wonder why we redefine those values?
>>
>> I wondered the same. Those redefines have been there since commit
On Thu, Jan 16, 2025 at 8:15 AM Nathan Bossart wrote:
> On Tue, Jan 14, 2025 at 11:08:05PM -0500, Tom Lane wrote:
> > Nathan Bossart writes:
> >> My guess is that this has something to do with redefining SIG_ERR in
> >> win32_port.h. We might be able to use push_macro/pop_macro to keep the old
>
enthusiasm for spending
> a lot of effort on this.
Assuming cfbot likes this new version of the patch, I'll commit it shortly.
Thanks for reviewing.
--
nathan
>From c7d182c41aa518f3b6479ee4bd6fdf6e8f2484c7 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Wed, 15 Jan 2025 13:04:58
Nathan Bossart writes:
> On Tue, Jan 14, 2025 at 10:02:46PM -0500, Tom Lane wrote:
>> LGTM, although I don't know enough about Windows to know if the
>> "== SIG_ERR" test in that path is correct.
> It's apparently not [0]. :(
Bleah.
> My guess is that this has something to do with redefining S
On Tue, Jan 14, 2025 at 10:02:46PM -0500, Tom Lane wrote:
> LGTM, although I don't know enough about Windows to know if the
> "== SIG_ERR" test in that path is correct.
It's apparently not [0]. :(
My guess is that this has something to do with redefining SIG_ERR in
win32_port.h. We might be abl
Nathan Bossart writes:
> Thanks to commit 9a45a89, legacy-pqsignal.c now has its own dedicated
> extern for pqsignal(), which decouples it enough that we can follow through
> with changing libpqport's pqsignal() to a void function.
> Thoughts?
LGTM, although I don't know enough about Windows to
ollow through
with changing libpqport's pqsignal() to a void function.
Thoughts?
--
nathan
>From 7b6e061be774d05d888bc5eac20e9aa09fc75403 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Tue, 14 Jan 2025 20:34:10 -0600
Subject: [PATCH v2 1/1] Convert libpgport's pqsignal() to a void fu
12 matches
Mail list logo
