Robert Haas writes:
> On Fri, Sep 11, 2020 at 4:20 PM Tom Lane wrote:
>> It's not clear to me whether we want to institute the "accepting SIGQUIT
>> is always okay" rule in processes that didn't already have code to change
>> BlockSig.
> I think a backend process that isn't timely handling SIGQU
On Fri, Sep 11, 2020 at 4:20 PM Tom Lane wrote:
> It's not clear to me whether we want to institute the "accepting SIGQUIT
> is always okay" rule in processes that didn't already have code to change
> BlockSig. The relevant processes are pgarch.c, startup.c, bgworker.c,
> autovacuum.c (launcher a
Robert Haas writes:
> On Thu, Sep 3, 2020 at 5:29 PM Tom Lane wrote:
>> Concretely, something about like this (I just did the bgwriter, but
>> we'd want the same in all the background processes). I tried to
>> respond to Robert's complaint about the inaccurate comment just above
>> sigsetjmp, to
On Thu, Sep 3, 2020 at 5:29 PM Tom Lane wrote:
> Concretely, something about like this (I just did the bgwriter, but
> we'd want the same in all the background processes). I tried to
> respond to Robert's complaint about the inaccurate comment just above
> sigsetjmp, too.
>
> This passes check-wo
I wrote:
> As for the question of SIGQUIT handling, I see that postgres.c
> does "PG_SETMASK(&BlockSig)" immediately after applying the sigdelset
> change, so there probably isn't any harm in having the background
> processes do likewise.
Concretely, something about like this (I just did the bgwri
On 2020-Sep-03, Tom Lane wrote:
> As for the question of SIGQUIT handling, I see that postgres.c
> does "PG_SETMASK(&BlockSig)" immediately after applying the sigdelset
> change, so there probably isn't any harm in having the background
> processes do likewise. I wonder though why bgworkers are n
vignesh C writes:
> The Solution Robert & Tom are suggesting by Calling
> BackgroundWorkerUnblockSignals fixes the actual problem.
I've gone ahead and pushed the bgworker fix, since everyone seems
to agree that that's okay, and it is provably fixing a problem.
As for the question of SIGQUIT hand
On Fri, Aug 7, 2020 at 1:34 AM Robert Haas wrote:
>
> On Tue, Jul 28, 2020 at 5:35 AM Bharath Rupireddy
> wrote:
> > The v4 patch looks good to me. Hang is not seen, make check and make
> > check-world passes. I moved this to the committer for further review
> > in https://commitfest.postgresql.o
On Fri, Aug 7, 2020 at 11:30 PM Tom Lane wrote:
>
> Robert Haas writes:
> > On Fri, Aug 7, 2020 at 12:56 PM Tom Lane wrote:
> >> That SETMASK call will certainly unblock SIGQUIT, so I don't see what
> >> your point is.
>
> > I can't figure out if you're trolling me here or what. It's true that
>
On Fri, Aug 7, 2020 at 2:00 PM Tom Lane wrote:
> The point of the sigdelset is that if somewhere later on, we install
> the BlockSig mask, then SIGQUIT will remain unblocked.
I mean, we're just repeating the same points here, but that's not what
the comment says.
> You asserted
> upthread that n
Robert Haas writes:
> On Fri, Aug 7, 2020 at 12:56 PM Tom Lane wrote:
>> That SETMASK call will certainly unblock SIGQUIT, so I don't see what
>> your point is.
> I can't figure out if you're trolling me here or what. It's true that
> the PG_SETMASK() call will certainly unblock SIGQUIT, but tha
On Fri, Aug 7, 2020 at 12:56 PM Tom Lane wrote:
> > I don't think that your analysis here is correct. The sigdelset call
> > is manipulating BlockSig, and the subsequent PG_SETMASK call is
> > working with UnblockSig, so it doesn't make sense to view one as a
> > preparatory step for the other.
>
Robert Haas writes:
> On Fri, Aug 7, 2020 at 11:36 AM Tom Lane wrote:
>> The sigdelset call, just like the adjacent pqsignal calls, is
>> preparatory setup; it does not intend to allow anything to happen
>> immediately.
> I don't think that your analysis here is correct. The sigdelset call
> is
On Fri, Aug 7, 2020 at 11:36 AM Tom Lane wrote:
> I think that code is the way it is intentionally: the idea is to not
> accept any signals until we reach the explicit "PG_SETMASK(&UnBlockSig);"
> call further down, between the sigsetjmp stanza and the main loop.
> The sigdelset call, just like th
Robert Haas writes:
> On Fri, Aug 7, 2020 at 5:05 AM Bharath Rupireddy
> wrote:
>> We intend to unblock SIGQUIT before sigsetjmp() in places like
>> bgwriter, checkpointer, walwriter and walreceiver, but we only call
>> sigdelset(&BlockSig, SIGQUIT);, Without PG_SETMASK(&BlockSig);, seems
>> lik
On Fri, Aug 7, 2020 at 5:05 AM Bharath Rupireddy
wrote:
> We intend to unblock SIGQUIT before sigsetjmp() in places like
> bgwriter, checkpointer, walwriter and walreceiver, but we only call
> sigdelset(&BlockSig, SIGQUIT);, Without PG_SETMASK(&BlockSig);, seems
> like we are not actually unblock
On Fri, Aug 7, 2020 at 1:34 AM Robert Haas wrote:
>
> On Tue, Jul 28, 2020 at 5:35 AM Bharath Rupireddy
> wrote:
> > The v4 patch looks good to me. Hang is not seen, make check and make
> > check-world passes. I moved this to the committer for further review
> > in https://commitfest.postgresql.o
On Tue, Jul 28, 2020 at 5:35 AM Bharath Rupireddy
wrote:
> The v4 patch looks good to me. Hang is not seen, make check and make
> check-world passes. I moved this to the committer for further review
> in https://commitfest.postgresql.org/29/2636/.
I don't think I agree with this approach. In part
On Tue, Jul 28, 2020 at 11:05 AM vignesh C wrote:
>
> Thanks for your comments Bharath.
>
> On Mon, Jul 27, 2020 at 10:13 AM Bharath Rupireddy
> wrote:
> > 1. Do we need "worker" as a function argument in
> > update_parallel_worker_sigmask(BackgroundWorker *worker, ? Since
> > MyBgworkerEntry
Thanks for your comments Bharath.
On Mon, Jul 27, 2020 at 10:13 AM Bharath Rupireddy
wrote:
> 1. Do we need "worker" as a function argument in
> update_parallel_worker_sigmask(BackgroundWorker *worker, ? Since
> MyBgworkerEntry is a global variable, can't we have a local variable
> instead?
On Sat, Jul 25, 2020 at 7:02 AM vignesh C wrote:
>
> I have made slight changes on top of the patch to remove duplicate
> code, attached v3 patch for the same.
> The parallel worker hang issue gets resolved, make check & make
> check-world passes.
>
Having a function to unblock selective signals
On Fri, Jul 24, 2020 at 12:41 PM Bharath Rupireddy
wrote:
>
> On Thu, Jul 23, 2020 at 12:54 PM vignesh C wrote:
> >
> > Thanks for reviewing and adding your thoughts, My comments are inline.
> >
> > On Fri, Jul 17, 2020 at 1:21 PM Bharath Rupireddy
> > wrote:
> > >
> > > The same hang issue can
On Thu, Jul 23, 2020 at 12:54 PM vignesh C wrote:
>
> Thanks for reviewing and adding your thoughts, My comments are inline.
>
> On Fri, Jul 17, 2020 at 1:21 PM Bharath Rupireddy
> wrote:
> >
> > The same hang issue can occur(though I'm not able to back it up with a
> > use case), in the cases fr
Thanks for reviewing and adding your thoughts, My comments are inline.
On Fri, Jul 17, 2020 at 1:21 PM Bharath Rupireddy
wrote:
>
> The same hang issue can occur(though I'm not able to back it up with a
> use case), in the cases from wherever the EmitErrorReport() is called
> from "if (sigsetjmp(
>
> Leader process then identifies that there are some messages that need
> to be processed, it copies the messages and sets the latch so that the
> worker process can copy the remaining message from the below function:
> shm_mq_inc_bytes_read -> SetLatch(&sender->procLatch);, Worker is not
> able
On Fri, Jul 3, 2020 at 2:40 PM vignesh C wrote:
>
> The Attached patch has the fix for the same.
>
I have added a commitfest entry for this bug:
https://commitfest.postgresql.org/29/2636/
Regards,
Vignesh
EnterpriseDB: http://www.enterprisedb.com
26 matches
Mail list logo
