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
On Tue, May 6, 2014 at 8:25 PM, Petr Jelinek p...@2ndquadrant.com 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
On 07/05/14 22:32, Robert Haas wrote:
On Tue, May 6, 2014 at 8:25 PM, Petr Jelinek p...@2ndquadrant.com 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
On Wed, May 7, 2014 at 4:55 PM, Petr Jelinek p...@2ndquadrant.com 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
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
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 Sun, May 4, 2014 at 9:57 AM, Petr Jelinek p...@2ndquadrant.com wrote:
On 30/04/14 23:35, Robert Haas wrote:
On Mon, Apr 28, 2014 at 4:19 PM, Petr Jelinek p...@2ndquadrant.com
wrote:
On 28/04/14 16:27, Robert Haas wrote:
It seems we have consensus on what to do about this, but what we
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
On 30/04/14 23:35, Robert Haas wrote:
On Mon, Apr 28, 2014 at 4:19 PM, Petr Jelinek p...@2ndquadrant.com 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
On Mon, Apr 28, 2014 at 4:19 PM, Petr Jelinek p...@2ndquadrant.com wrote:
On 28/04/14 16:27, Robert Haas wrote:
On Thu, Apr 24, 2014 at 1:39 AM, Craig Ringer cr...@2ndquadrant.com
wrote:
On 04/17/2014 08:35 AM, Craig Ringer wrote:
I've just noticed that the bgworker control interfaces do not
On Thu, Apr 24, 2014 at 1:39 AM, Craig Ringer cr...@2ndquadrant.com 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
On 28/04/14 16:27, Robert Haas wrote:
On Thu, Apr 24, 2014 at 1:39 AM, Craig Ringer cr...@2ndquadrant.com 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
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
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 sorted out
On 2014-02-03 11:29:22 -0500, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Feb 3, 2014 at 10:20 AM, Tom Lane t...@sss.pgh.pa.us wrote:
So
exit(0) - done, permanently
exit(1) - done until restart interval
exit(other) - crash
and there's no way to obtain the restart
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
On Wed, Apr 16, 2014 at 9:10 AM, Andres Freund and...@2ndquadrant.com 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
On 2014-04-16 10:37:12 -0400, Robert Haas wrote:
On Wed, Apr 16, 2014 at 9:10 AM, Andres Freund and...@2ndquadrant.com 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 11:28 AM, Andres Freund and...@2ndquadrant.com 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
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 only
Andres Freund and...@2ndquadrant.com 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
On 2014-04-16 11:54:25 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com 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
On Wed, Apr 16, 2014 at 12:00 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-04-16 11:54:25 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-04-16 11:37:47 -0400, Robert Haas wrote:
Why can't that be handled through ereport(ERROR/FATAL) rather than
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 it
On Wed, Apr 16, 2014 at 12:11 PM, Andres Freund and...@2ndquadrant.com 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
On 2014-04-16 12:20:01 -0400, Robert Haas wrote:
On Wed, Apr 16, 2014 at 12:11 PM, Andres Freund and...@2ndquadrant.com
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
On Wed, Apr 16, 2014 at 12:28 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-04-16 12:20:01 -0400, Robert Haas wrote:
On Wed, Apr 16, 2014 at 12:11 PM, Andres Freund and...@2ndquadrant.com
wrote:
On 2014-04-16 12:04:26 -0400, Robert Haas wrote:
And... so what's the problem? You
On 16/04/14 18:34, Robert Haas wrote:
On Wed, Apr 16, 2014 at 12:28 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-04-16 12:20:01 -0400, Robert Haas wrote:
On Wed, Apr 16, 2014 at 12:11 PM, Andres Freund and...@2ndquadrant.com wrote:
I'm still not seeing the problem. It's the
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 Fri, Jan 31, 2014 at 12:44 PM, Antonin Houska
antonin.hou...@gmail.com 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
Robert Haas robertmh...@gmail.com 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
On Mon, Feb 3, 2014 at 10:20 AM, Tom Lane t...@sss.pgh.pa.us 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
Robert Haas robertmh...@gmail.com writes:
On Mon, Feb 3, 2014 at 10:20 AM, Tom Lane t...@sss.pgh.pa.us 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
On Mon, Feb 3, 2014 at 11:29 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Feb 3, 2014 at 10:20 AM, Tom Lane t...@sss.pgh.pa.us wrote:
So
exit(0) - done, permanently
exit(1) - done until restart interval
exit(other) - crash
and there's no way to
Robert Haas robertmh...@gmail.com writes:
On Mon, Feb 3, 2014 at 11:29 AM, Tom Lane t...@sss.pgh.pa.us 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
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
36 matches
Mail list logo
