Re: convert libpgport's pqsignal() to a void function
От | Nathan Bossart |
---|---|
Тема | Re: convert libpgport's pqsignal() to a void function |
Дата | |
Msg-id | Z4gQxiLQrf5OLf18@nathan обсуждение исходный текст |
Ответ на | Re: convert libpgport's pqsignal() to a void function (Thomas Munro <thomas.munro@gmail.com>) |
Ответы |
Re: convert libpgport's pqsignal() to a void function
Re: convert libpgport's pqsignal() to a void function |
Список | pgsql-hackers |
On Thu, Jan 16, 2025 at 08:21:08AM +1300, Thomas Munro wrote: > On Thu, Jan 16, 2025 at 8:15 AM Nathan Bossart <nathandbossart@gmail.com> 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 5049196, >> but I haven't been able to find any real discussion in the archives about >> it. Maybe I will bug Magnus about it sometime, in case he happens to >> remember the reason. > > My guess would be: perhaps some ancient version of MinGW didn't define > them? They're defined by MinGW and native signal.h now and they have > the same values, so we should remove them I think. Okay. If nothing else, it'd be interesting to see what the buildfarm thinks. > Assertion failed: 0, file ../src/port/pqsignal.c, line 147 > > 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 than my SIG_ERR redefinition theory. If that assertion is getting hit, that means signal() _is_ returning SIG_ERR (either the system one or our redefined version), and it looks like it's pretty common to use -1 for SIG_ERR. That'd only affect Windows frontend programs, but it still sounds scary. I'll try getting more details about the error with some custom cfbot runs. -- nathan
В списке pgsql-hackers по дате отправления: