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
locking or unblocking SIGQUIT in these
processes after the sigsetjmp() stanza, as it anyways gets unblocked
by PG_SETMASK(&UnBlockSig); and also no problem if somebody does
PG_SETMASK(&BlockSig); in future as we have already done
sigdelset(&BlockSig, SIGQUIT);.
Can we start a separate
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
worker.sgml as well.
Included the documentation.
Attached the updated patch for the same.
Regards,
Vignesh
EnterpriseDB: http://www.enterprisedb.com
From f06a5966d754d6622a3425c6cac1ad72314832ef Mon Sep 17 00:00:00 2001
From: Vignesh C
Date: Tue, 28 Jul 2020 10:48:17 +0530
Subject: [PATCH v4]
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
;
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.
Regards,
Vignesh
EnterpriseDB: http://www.enterprisedb.com
From b48849d091302dfdac4fc004195b3c532fdb9d
py hang issue. And also make
check and make check-world passes.
With Regards,
Bharath Rupireddy.
EnterpriseDB: http://www.enterprisedb.com
From 6bd924f2e7ff90d6c293f131b8ddb20898b9950d Mon Sep 17 00:00:00 2001
From: Bharath Rupireddy
Date: Fri, 24 Jul 2020 12:01:14 +0530
Subject: [PATCH v2] Fix for
gworker.c as we require the parallel worker to receive this signal
and continue processing. I have not included the changes for other
processes as I'm not sure if this scenario is applicable for other
processes.
Regards,
Vignesh
EnterpriseDB: http://www.enterprisedb.com
From b283bdd47e3bc132
>
> 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
Hi,
Parallel worker hangs while handling errors.
Analysis:
When there is an error in the parallel worker process, we will call
ereport/elog with the error message. Worker will then jump from
errfinish to setjmp in StartBackgroundWorker function which was set
earlier. Then the worker process will
27 matches
Mail list logo
