Re: EINTR in ftruncate()
От | Thomas Munro |
---|---|
Тема | Re: EINTR in ftruncate() |
Дата | |
Msg-id | CA+hUKGKKKfcgx6jzok9AYenp2TNti_tfs8FMoJpL8+0Gsy==_A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: EINTR in ftruncate() (Thomas Munro <thomas.munro@gmail.com>) |
Ответы |
Re: EINTR in ftruncate()
Re: EINTR in ftruncate() |
Список | pgsql-hackers |
On Sat, Jul 16, 2022 at 5:18 PM Thomas Munro <thomas.munro@gmail.com> wrote: > On Sat, Jul 16, 2022 at 1:28 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Thomas Munro <thomas.munro@gmail.com> writes: > > > On Fri, Jul 15, 2022 at 9:34 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > >> (Someday we oughta go ahead and make our Windows signal API look more > > >> like POSIX, as I suggested back in 2015. I'm still not taking > > >> point on that, though.) > > > > > For the sigprocmask() part, here's a patch that passes CI. Only the > > > SIG_SETMASK case is actually exercised by our current code, though. > > > > Passes an eyeball check, but I can't actually test it. > > Thanks. Pushed. > > I'm not brave enough to try to write a replacement sigaction() yet, > but it does appear that we could rip more ugliness and inconsistencies > that way, eg sa_mask. Here's a draft patch that adds a minimal sigaction() implementation for Windows. It doesn't implement stuff we're not using, for sample sa_sigaction functions, but it has the sa_mask feature so we can harmonize the stuff that I believe you were talking about.
Вложения
В списке pgsql-hackers по дате отправления: