On Wed, Aug 17, 2022 at 7:51 AM Thomas Munro wrote:
> On Sat, Jul 16, 2022 at 5:18 PM Thomas Munro wrote:
> > On Sat, Jul 16, 2022 at 1:28 AM Tom Lane wrote:
> > > Thomas Munro writes:
> > > > On Fri, Jul 15, 2022 at 9:34 AM Tom Lane wrote:
> > > >> (Someday we oughta go ahead and make our
Hi,
On 2022-09-30 13:53:45 -0500, Justin Pryzby wrote:
> On Wed, Aug 17, 2022 at 07:51:34AM +1200, Thomas Munro wrote:
> > 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
On Wed, Aug 17, 2022 at 07:51:34AM +1200, Thomas Munro wrote:
> 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
On Sat, Jul 16, 2022 at 5:18 PM Thomas Munro wrote:
> On Sat, Jul 16, 2022 at 1:28 AM Tom Lane wrote:
> > Thomas Munro writes:
> > > On Fri, Jul 15, 2022 at 9:34 AM Tom Lane wrote:
> > >> (Someday we oughta go ahead and make our Windows signal API look more
> > >> like POSIX, as I suggested
On Sat, Jul 16, 2022 at 1:28 AM Tom Lane wrote:
> Thomas Munro writes:
> > On Fri, Jul 15, 2022 at 9:34 AM Tom Lane 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.)
Thomas Munro writes:
> On Fri, Jul 15, 2022 at 9:34 AM Tom Lane 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
On Fri, Jul 15, 2022 at 9:34 AM Tom Lane 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
Thomas Munro writes:
> So why would I add another wrapper like PG_SETMASK and leave it
> unimplemented for now on Windows, when I could just use sigprocmask()
> directly and leave it unimplemented for now on Windows?
Fair enough, I guess. No objection to this patch.
(Someday we oughta go ahead
On Fri, Jul 15, 2022 at 3:27 AM Tom Lane wrote:
> Alvaro Herrera writes:
> > ISTM it would be cleaner to patch PG_SETMASK to have a second argument
> > and to return the original mask if that's not NULL. This is more
> > invasive, but there aren't that many callsites of that macro.
>
> [
Thomas Munro writes:
> ... but now I'm wondering if we should be more defensive and possibly
> even save/restore the mask.
+1, sounds like a more future-proof solution.
> Originally I discounted that because I
> thought I had to go through PG_SETMASK for portability reasons, but on
> closer
Alvaro Herrera writes:
> ISTM it would be cleaner to patch PG_SETMASK to have a second argument
> and to return the original mask if that's not NULL. This is more
> invasive, but there aren't that many callsites of that macro.
[ shoulda read your message before replying ]
Given that this needs
On 2022-Jul-15, Thomas Munro wrote:
> I checked that this throw-away assertion doesn't fail currently:
>
> if (IsUnderPostmaster)
> + {
> + sigset_t old;
> + sigprocmask(SIG_SETMASK, NULL, );
> + Assert(memcmp(, , sizeof(UnBlockSig)) == 0);
On Fri, Jul 15, 2022 at 1:02 AM Thomas Munro wrote:
> On Fri, Jul 15, 2022 at 12:15 AM Thomas Munro wrote:
> > Yeah. Done, and pushed. 0002 not back-patched.
>
> Hmm, there were a couple of hard to understand build farm failures.
> My first thought is that the signal mask stuff should only be
On Fri, Jul 15, 2022 at 12:15 AM Thomas Munro wrote:
> Yeah. Done, and pushed. 0002 not back-patched.
Hmm, there were a couple of hard to understand build farm failures.
My first thought is that the signal mask stuff should only be done if
IsUnderPostmaster, otherwise it clobbers the
On Tue, Jul 12, 2022 at 5:45 AM Andres Freund wrote:
> Hm - given that we've observed ftruncate failing with strace, and that
> stracing to find problems isn't insane, shouldn't we retry the ftruncate too?
> It's kind of obsoleted by your next patch, but not really, because it's not
>
Hi,
On 2022-07-07 17:58:10 +1200, Thomas Munro wrote:
> Even if we go with this approach now, I think it's plausible that we
> might want to reconsider this yet again one day, perhaps allocating
> memory with some future asynchronous infrastructure while still
> processing interrupts. It's not
On 2022-Jul-07, Thomas Munro wrote:
> On Thu, Jul 7, 2022 at 9:05 AM Thomas Munro wrote:
> > On Thu, Jul 7, 2022 at 9:03 AM Andres Freund wrote:
> > > On 2022-07-07 08:56:33 +1200, Thomas Munro wrote:
> > > > On Thu, Jul 7, 2022 at 8:39 AM Andres Freund wrote:
> > > > > So I think we need: 1)
On Thu, Jul 7, 2022 at 9:05 AM Thomas Munro wrote:
> On Thu, Jul 7, 2022 at 9:03 AM Andres Freund wrote:
> > On 2022-07-07 08:56:33 +1200, Thomas Munro wrote:
> > > On Thu, Jul 7, 2022 at 8:39 AM Andres Freund wrote:
> > > > So I think we need: 1) block most signals, 2) a retry loop *without*
>
On Thu, Jul 7, 2022 at 9:03 AM Andres Freund wrote:
> On 2022-07-07 08:56:33 +1200, Thomas Munro wrote:
> > On Thu, Jul 7, 2022 at 8:39 AM Andres Freund wrote:
> > > So I think we need: 1) block most signals, 2) a retry loop *without*
> > > interrupt checks.
> >
> > Yeah. I was also wondering
Hi,
On 2022-07-07 08:56:33 +1200, Thomas Munro wrote:
> On Thu, Jul 7, 2022 at 8:39 AM Andres Freund wrote:
> > So I think we need: 1) block most signals, 2) a retry loop *without*
> > interrupt checks.
>
> Yeah. I was also wondering about wrapping the whole function in
> PG_SETMASK(),
On Thu, Jul 7, 2022 at 8:39 AM Andres Freund wrote:
> On 2022-07-06 21:29:41 +0200, Alvaro Herrera wrote:
> > On 2022-Jul-05, Andres Freund wrote:
> >
> > > I think we'd be better off disabling at least some signals during
> > > dsm_impl_posix_resize(). I'm afraid we'll otherwise just find
Hi,
On 2022-07-06 21:29:41 +0200, Alvaro Herrera wrote:
> On 2022-Jul-05, Andres Freund wrote:
>
> > I think we'd be better off disabling at least some signals during
> > dsm_impl_posix_resize(). I'm afraid we'll otherwise just find another
> > variation of these problems. I haven't checked the
On 2022-Jul-05, Andres Freund wrote:
> I think we'd be better off disabling at least some signals during
> dsm_impl_posix_resize(). I'm afraid we'll otherwise just find another
> variation of these problems. I haven't checked the source of ftruncate, but
> what Thomas dug up for fallocate makes
Hi,
On 2022-07-04 13:07:50 +0200, Alvaro Herrera wrote:
> On 2022-Jul-01, Andres Freund wrote:
>
> > On 2022-07-01 19:55:16 +0200, Alvaro Herrera wrote:
> > > On 2022-Jul-01, Andres Freund wrote:
>
> > > > What is the reason for the || ProcDiePending || QueryCancelPending bit?
> > > > What
> >
On 2022-Jul-01, Andres Freund wrote:
> On 2022-07-01 19:55:16 +0200, Alvaro Herrera wrote:
> > On 2022-Jul-01, Andres Freund wrote:
> > > What is the reason for the || ProcDiePending || QueryCancelPending bit?
> > > What
> > > if there's dsm operations intentionally done while
Hi,
On 2022-07-02 09:52:33 +1200, Thomas Munro wrote:
> On Sat, Jul 2, 2022 at 9:06 AM Andres Freund wrote:
> > On 2022-07-01 13:29:44 -0700, Andres Freund wrote:
> > Chris, do you have any additional details about the machine that lead to
> > this
> > change? OS version, whether it might have
On Sat, Jul 2, 2022 at 9:06 AM Andres Freund wrote:
> On 2022-07-01 13:29:44 -0700, Andres Freund wrote:
> > On 2022-07-01 19:55:16 +0200, Alvaro Herrera wrote:
> > > Allow DSM allocation to be interrupted.
> > >
> > > Chris Travers reported that the startup process can repeatedly try to
Hi Chris,
On 2022-07-01 13:29:44 -0700, Andres Freund wrote:
> On 2022-07-01 19:55:16 +0200, Alvaro Herrera wrote:
> > On 2022-Jul-01, Andres Freund wrote:
> >
> > > On 2022-07-01 17:41:05 +0200, Alvaro Herrera wrote:
> > > > Nicola Contu reported two years ago to pgsql-general[1] that they were
Hi,
On 2022-07-01 19:55:16 +0200, Alvaro Herrera wrote:
> On 2022-Jul-01, Andres Freund wrote:
>
> > On 2022-07-01 17:41:05 +0200, Alvaro Herrera wrote:
> > > Nicola Contu reported two years ago to pgsql-general[1] that they were
> > > having sporadic query failures, because EINTR is reported on
On 2022-Jul-01, Andres Freund wrote:
> On 2022-07-01 17:41:05 +0200, Alvaro Herrera wrote:
> > Nicola Contu reported two years ago to pgsql-general[1] that they were
> > having sporadic query failures, because EINTR is reported on some system
> > call. I have been told that the problem persists,
Hi,
On 2022-07-01 17:41:05 +0200, Alvaro Herrera wrote:
> Nicola Contu reported two years ago to pgsql-general[1] that they were
> having sporadic query failures, because EINTR is reported on some system
> call. I have been told that the problem persists, though it is very
> infrequent. I
Nicola Contu reported two years ago to pgsql-general[1] that they were
having sporadic query failures, because EINTR is reported on some system
call. I have been told that the problem persists, though it is very
infrequent. I propose the attached patch. Kyotaro proposed a slightly
different
32 matches
Mail list logo
