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
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
pgkill(), etc. My next thought was to simply ignore signal() err
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
>
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
>> value around, but at the moment I'm leaning towards just remo
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
11 matches
Mail list logo
