On 05/08/2014 05:45 AM, Robert Haas wrote:
> I've pushed your rebased patch now with some further kibitzing,
> especially in regards to the documentation.
Thanks for tacking that Robert. It's great to have that API sorted out
before 9.4 hits and it's locked in.
--
Craig Ringer
On 07/05/14 23:45, Robert Haas wrote:
It was, but I felt that the different pieces of this should be
separated into separate commits, and (regardless of how I committed
it) I needed to review each change separately. I wasn't saying it was
your fault that it wasn't done; just that I hadn't gotten
On Wed, May 7, 2014 at 4:55 PM, Petr Jelinek wrote:
>> This isn't done yet.
>
> Unless I am missing something this change was included in every patch I sent
> - setting rw->rw_terminate = true; in CleanupBackgroundWorker for zero exit
> code + comment changes. Or do you have objections to this app
On 07/05/14 22:32, Robert Haas wrote:
On Tue, May 6, 2014 at 8:25 PM, Petr Jelinek wrote:
I've committed the portion of your patch which does this, with pretty
extensive changes. I moved the function which resets the crash times
to bgworker.c, renamed it, and made it just reset all of the crash
On Tue, May 6, 2014 at 8:25 PM, Petr Jelinek wrote:
>> What I'm inclined to do is change the logic so that:
>>
>> (1) After a crash-and-restart sequence, zero rw->rw_crashed_at, so
>> that anything which is still registered gets restarted immediately.
>
> Yes, that's quite obvious change which I m
On 07/05/14 02:25, Petr Jelinek wrote:
On 06/05/14 19:05, Robert Haas wrote:
What I'm inclined to do is change the logic so that:
(1) After a crash-and-restart sequence, zero rw->rw_crashed_at, so
that anything which is still registered gets restarted immediately.
Yes, that's quite obvious ch
On 06/05/14 19:05, Robert Haas wrote:
Which brings up another point: the behavior of non-shmem-connected
workers is totally bizarre. An exit status other than 0 or 1 is not
treated as a crash requiring a restart, but failure to disengage the
deadman switch is still treated as a crash requiring a
On Sun, May 4, 2014 at 9:57 AM, Petr Jelinek wrote:
> On 30/04/14 23:35, Robert Haas wrote:
>> On Mon, Apr 28, 2014 at 4:19 PM, Petr Jelinek
>> wrote:
>>> On 28/04/14 16:27, Robert Haas wrote:
It seems we have consensus on what to do about this, but what we
haven't got is a patch.
>>>
>
On 30/04/14 23:35, Robert Haas wrote:
On Mon, Apr 28, 2014 at 4:19 PM, Petr Jelinek wrote:
On 28/04/14 16:27, Robert Haas wrote:
It seems we have consensus on what to do about this, but what we
haven't got is a patch.
If you mean the consensus that exit status 0 should mean permanent stop t
On Mon, Apr 28, 2014 at 4:19 PM, Petr Jelinek wrote:
> On 28/04/14 16:27, Robert Haas wrote:
>> On Thu, Apr 24, 2014 at 1:39 AM, Craig Ringer
>> wrote:
>>> On 04/17/2014 08:35 AM, Craig Ringer wrote:
>>> I've just noticed that the bgworker control interfaces do not honour
>>> bgw.bgw_restart_time
On 28/04/14 16:27, Robert Haas wrote:
On Thu, Apr 24, 2014 at 1:39 AM, Craig Ringer wrote:
On 04/17/2014 08:35 AM, Craig Ringer wrote:
I've just noticed that the bgworker control interfaces do not honour
bgw.bgw_restart_time = BGW_NEVER_RESTART if you exit with status zero.
This means that it'
On Thu, Apr 24, 2014 at 1:39 AM, Craig Ringer wrote:
> On 04/17/2014 08:35 AM, Craig Ringer wrote:
>> On 04/17/2014 04:47 AM, Petr Jelinek wrote:
>>>
>>> Well the logging is just too spammy in general when it comes to dynamic
>>> bgworkers but that's easy to fix in the future, no need to make
>>>
On 24/04/14 07:39, Craig Ringer wrote:
On 04/17/2014 08:35 AM, Craig Ringer wrote:
As far as I can tell we have a couple of options:
- Redefine what the exit codes mean so that exit 0 suppresses
auto-restart and exits silently. Probably simplest.
I'm now strongly in favour of this alternativ
On 04/17/2014 08:35 AM, Craig Ringer wrote:
> On 04/17/2014 04:47 AM, Petr Jelinek wrote:
>>
>> Well the logging is just too spammy in general when it comes to dynamic
>> bgworkers but that's easy to fix in the future, no need to make
>> decisions for 9.4.
>
> Agreed - it's the *API* that we need
On 04/17/2014 04:47 AM, Petr Jelinek wrote:
>
> Well the logging is just too spammy in general when it comes to dynamic
> bgworkers but that's easy to fix in the future, no need to make
> decisions for 9.4.
Agreed - it's the *API* that we need sorted out for 9.4, and log output
isn't something Pg
On 16/04/14 18:34, Robert Haas wrote:
On Wed, Apr 16, 2014 at 12:28 PM, Andres Freund wrote:
On 2014-04-16 12:20:01 -0400, Robert Haas wrote:
On Wed, Apr 16, 2014 at 12:11 PM, Andres Freund wrote:
I'm still not seeing the problem. It's the background worker's job to
make sure that the right
On Wed, Apr 16, 2014 at 12:28 PM, Andres Freund wrote:
> On 2014-04-16 12:20:01 -0400, Robert Haas wrote:
>> On Wed, Apr 16, 2014 at 12:11 PM, Andres Freund
>> wrote:
>> > On 2014-04-16 12:04:26 -0400, Robert Haas wrote:
>> >> And... so what's the problem? You seemed to be saying that the
>> >>
On 2014-04-16 12:20:01 -0400, Robert Haas wrote:
> On Wed, Apr 16, 2014 at 12:11 PM, Andres Freund
> wrote:
> > On 2014-04-16 12:04:26 -0400, Robert Haas wrote:
> >> And... so what's the problem? You seemed to be saying that the
> >> background worker would need to a more developed error-handlin
On Wed, Apr 16, 2014 at 12:11 PM, Andres Freund wrote:
> On 2014-04-16 12:04:26 -0400, Robert Haas wrote:
>> And... so what's the problem? You seemed to be saying that the
>> background worker would need to a more developed error-handling
>> environment in order to do proper logging, but here you
On 2014-04-16 12:04:26 -0400, Robert Haas wrote:
> And... so what's the problem? You seemed to be saying that the
> background worker would need to a more developed error-handling
> environment in order to do proper logging, but here you're saying
> (rightly, I believe) that it doesn't. Even if i
On Wed, Apr 16, 2014 at 12:00 PM, Andres Freund wrote:
> On 2014-04-16 11:54:25 -0400, Tom Lane wrote:
>> Andres Freund writes:
>> > On 2014-04-16 11:37:47 -0400, Robert Haas wrote:
>> >> Why can't that be handled through ereport(ERROR/FATAL) rather than
>> >> through the choice of exit status?
>
On 2014-04-16 11:54:25 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-04-16 11:37:47 -0400, Robert Haas wrote:
> >> Why can't that be handled through ereport(ERROR/FATAL) rather than
> >> through the choice of exit status?
>
> > I dislike that because it essentially requires the bgwor
Andres Freund writes:
> On 2014-04-16 11:37:47 -0400, Robert Haas wrote:
>> Why can't that be handled through ereport(ERROR/FATAL) rather than
>> through the choice of exit status?
> I dislike that because it essentially requires the bgworker to have a
> full error catching environment like Postg
On 2014-04-16 11:37:47 -0400, Robert Haas wrote:
> > I think we probably also need a way to exit that's treated as an error,
> > but doesn't lead to a PANIC restart.
>
> Why can't that be handled through ereport(ERROR/FATAL) rather than
> through the choice of exit status? It seems to me that the
On Wed, Apr 16, 2014 at 11:28 AM, Andres Freund wrote:
>> I actually think the right answer here might be to give background
>> workers a way to change their configured restart interval. We've
>> already got a shared memory area that the postmaster reads to know how
>> what to do when starting a
On 2014-04-16 10:37:12 -0400, Robert Haas wrote:
> On Wed, Apr 16, 2014 at 9:10 AM, Andres Freund wrote:
> >> Agreed, but after further reflection it seems like if you've declared
> >> a restart interval, then "done until restart interval" is probably the
> >> common case. So how about
> >>
> >>
On Wed, Apr 16, 2014 at 9:10 AM, Andres Freund wrote:
>> Agreed, but after further reflection it seems like if you've declared
>> a restart interval, then "done until restart interval" is probably the
>> common case. So how about
>>
>> exit(0) - done until restart interval, or permanently if ther
On 16/04/14 15:10, Andres Freund wrote:
I think we really should bite the bullet and change this before 9.4
comes out. The current static bgworker facility has only been out there
for one release, and dynamic bgworkers aren't released yet at all. If we
wait with this for 9.5, we'll annoy many mo
On 2014-02-03 11:29:22 -0500, Tom Lane wrote:
> Robert Haas writes:
> > On Mon, Feb 3, 2014 at 10:20 AM, Tom Lane wrote:
> >> So
> >> exit(0) - done, permanently
> >> exit(1) - done until restart interval
> >> exit(other) - crash
> >> and there's no way to obtain the "restart immediately" behavio
Robert Haas writes:
> On Mon, Feb 3, 2014 at 11:29 AM, Tom Lane wrote:
>> Agreed, but after further reflection it seems like if you've declared
>> a restart interval, then "done until restart interval" is probably the
>> common case. So how about ...
> I think what I proposed is better for two
On Mon, Feb 3, 2014 at 11:29 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Feb 3, 2014 at 10:20 AM, Tom Lane wrote:
>>> So
>>> exit(0) - done, permanently
>>> exit(1) - done until restart interval
>>> exit(other) - crash
>>> and there's no way to obtain the "restart immediately" behavior?
Robert Haas writes:
> On Mon, Feb 3, 2014 at 10:20 AM, Tom Lane wrote:
>> So
>> exit(0) - done, permanently
>> exit(1) - done until restart interval
>> exit(other) - crash
>> and there's no way to obtain the "restart immediately" behavior?
> That's what I was thinking about, yes. Of course, whe
On Mon, Feb 3, 2014 at 10:20 AM, Tom Lane wrote:
> So
> exit(0) - done, permanently
> exit(1) - done until restart interval
> exit(other) - crash
> and there's no way to obtain the "restart immediately" behavior?
That's what I was thinking about, yes. Of course, when the
Robert Haas writes:
> This is admittedly a weird API, and we've had some discussion of
> whether to change it, but I don't know that we've reached any final
> conclusion. I'm tempted to propose exactly inverting the current
> meaning of exit(0). That is, make it mean "don't restart me, ever,
> e
On Fri, Jan 31, 2014 at 12:44 PM, Antonin Houska
wrote:
> In 9.3 I noticed that postmaster considers bgworker crashed (and
> therefore tries to restart it) even if it has exited with zero status code.
>
> I first thought about a patch like the one below, but then noticed that
> postmaster.c:bgwork
In 9.3 I noticed that postmaster considers bgworker crashed (and
therefore tries to restart it) even if it has exited with zero status code.
I first thought about a patch like the one below, but then noticed that
postmaster.c:bgworker_quickdie() signal handler exits with 0 too (when
there's no suc
36 matches
Mail list logo
