On 27 May 2011 10:01, Florian Pflug wrote:
> Anyway, I'm glad to see that Peter Geoghegan has picked this up
> any turned this into an actual patch.
>
> Extremely cool!
Thanks Florian.
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Servi
On May7, 2011, at 03:50 , Robert Haas wrote:
> On Sat, Jan 15, 2011 at 10:44 AM, Florian Pflug wrote:
>> I've realized that POSIX actually *does* provide a way to receive a signal -
>> the SIGIO machinery. I've modified my test case do to that. To simplify
>> things,
>> I've removed support for m
On Sat, Jan 15, 2011 at 10:44 AM, Florian Pflug wrote:
> On Jan14, 2011, at 17:45 , Robert Haas wrote:
>> On Fri, Jan 14, 2011 at 11:28 AM, Florian Pflug wrote:
>>> I gather that the behaviour we want is for normal backends to exit
>>> once the postmaster is gone, and for utility processes (bgwri
On Jan14, 2011, at 17:45 , Robert Haas wrote:
> On Fri, Jan 14, 2011 at 11:28 AM, Florian Pflug wrote:
>> I gather that the behaviour we want is for normal backends to exit
>> once the postmaster is gone, and for utility processes (bgwriter, ...)
>> to exit once all the backends are gone.
>>
>> T
On Sat, Jan 15, 2011 at 6:27 AM, Florian Pflug wrote:
> On Jan14, 2011, at 17:45 , Robert Haas wrote:
>> On Fri, Jan 14, 2011 at 11:28 AM, Florian Pflug wrote:
>>> I gather that the behaviour we want is for normal backends to exit
>>> once the postmaster is gone, and for utility processes (bgwrit
On Jan14, 2011, at 17:45 , Robert Haas wrote:
> On Fri, Jan 14, 2011 at 11:28 AM, Florian Pflug wrote:
>> I gather that the behaviour we want is for normal backends to exit
>> once the postmaster is gone, and for utility processes (bgwriter, ...)
>> to exit once all the backends are gone.
>>
>> T
On Fri, Jan 14, 2011 at 11:28 AM, Florian Pflug wrote:
> I gather that the behaviour we want is for normal backends to exit
> once the postmaster is gone, and for utility processes (bgwriter, ...)
> to exit once all the backends are gone.
>
> The test program I posted in this thread proves that FI
On Jan14, 2011, at 17:22 , Kevin Grittner wrote:
> Alvaro Herrera wrote:
>
>> If postmaster dies, and then another backend crashes, then your
>> backend running "your honking big query" could run across
>> corrupted state and then you'd be in serious trouble.
>
> Worst of all, it could give bog
Alvaro Herrera wrote:
> If postmaster dies, and then another backend crashes, then your
> backend running "your honking big query" could run across
> corrupted state and then you'd be in serious trouble.
Worst of all, it could give bogus results without error. I really
don't see a production
Excerpts from Robert Haas's message of vie ene 14 00:03:53 -0300 2011:
> On Thu, Jan 13, 2011 at 8:28 PM, Tom Lane wrote:
> > True. It strikes me also that the postmaster does provide some services
> > other than accepting new connections:
> >
> > * ensuring that everybody gets killed if a backe
On Thu, Jan 13, 2011 at 8:28 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jan 13, 2011 at 8:10 PM, Tom Lane wrote:
>>> Florian Pflug writes:
So maybe there should be a GUC for this?
>
>>> No need (and rather inflexible anyway). If you don't want an orphaned
>>> backend to continue
Robert Haas writes:
> On Thu, Jan 13, 2011 at 8:10 PM, Tom Lane wrote:
>> Florian Pflug writes:
>>> So maybe there should be a GUC for this?
>> No need (and rather inflexible anyway). If you don't want an orphaned
>> backend to continue, you send it SIGTERM.
> It is not easy to make this work
On Thu, Jan 13, 2011 at 8:10 PM, Tom Lane wrote:
> Florian Pflug writes:
>> I don't believe there's one right answer to that.
>
> Right. Force-kill presumes there is only one right answer.
>
>> Assume postgres is driving a website, and the postmaster crashes shortly
>> after a pg_dump run starte
On Thu, Jan 13, 2011 at 7:32 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jan 13, 2011 at 3:37 PM, Tom Lane wrote:
>>> Killing active sessions when it's not absolutely necessary is not an
>>> asset.
>
>> That's a highly arguable point and I certainly don't agree with it.
>
> Your example
Florian Pflug writes:
> I don't believe there's one right answer to that.
Right. Force-kill presumes there is only one right answer.
> Assume postgres is driving a website, and the postmaster crashes shortly
> after a pg_dump run started. You probably won't want your website to be
> offline whi
On Jan14, 2011, at 01:32 , Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jan 13, 2011 at 3:37 PM, Tom Lane wrote:
>>> Killing active sessions when it's not absolutely necessary is not an
>>> asset.
>
>> That's a highly arguable point and I certainly don't agree with it.
>
> Your examples app
Robert Haas writes:
> On Thu, Jan 13, 2011 at 3:37 PM, Tom Lane wrote:
>> Killing active sessions when it's not absolutely necessary is not an
>> asset.
> That's a highly arguable point and I certainly don't agree with it.
Your examples appear to rely on the assumption that background processes
On Thu, Jan 13, 2011 at 03:29:13PM -0800, Jeff Davis wrote:
> On Thu, 2011-01-13 at 11:14 -0800, David Fetter wrote:
> > I get that we can't prevent all pilot error, but I was hoping we
> > could bullet-proof this a little more, especially in light of a
> > certain extremely popular server OS's OOM
On Thu, 2011-01-13 at 11:14 -0800, David Fetter wrote:
> I get that we can't prevent all pilot error, but I was hoping we could
> bullet-proof this a little more, especially in light of a certain
> extremely popular server OS's OOM killer's default behavior.
That's a good point. I'm not sure how m
On Jan13, 2011, at 21:42 , Tom Lane wrote:
> Aidan Van Dyk writes:
>> If postmaster has a few fds to spare, what about having it open a pipe
>> to every child it spawns. It never has to read/write to it, but
>> postmaster closing will signal the client's fd. The client just has
>> to pop the fd
On Thu, Jan 13, 2011 at 02:21:44PM -0500, Tom Lane wrote:
> David Fetter writes:
> > I get that we can't prevent all pilot error, but I was hoping we
> > could bullet-proof this a little more, especially in light of a
> > certain extremely popular server OS's OOM killer's default
> > behavior.
>
On Thu, Jan 13, 2011 at 3:37 PM, Tom Lane wrote:
> Robert Haas writes:
>> I strongly believe you're in the minority on that one, for the same
>> reasons that I don't think most people would agree with your notion of
>> what should be the default shutdown mode. A database that can't
>> accept new
On Thu, Jan 13, 2011 at 09:18:06PM +0100, Florian Pflug wrote:
> On Jan13, 2011, at 21:01 , Aidan Van Dyk wrote:
> > On Thu, Jan 13, 2011 at 2:53 PM, Robert Haas wrote:
> >> I'm not convinced. I was thinking that we could simply treat it
> >> like SIGQUIT, if it's available. I doubt there's a re
Aidan Van Dyk writes:
> If postmaster has a few fds to spare, what about having it open a pipe
> to every child it spawns. It never has to read/write to it, but
> postmaster closing will signal the client's fd. The client just has
> to pop the fd into whatever nrmal poll/select event handlign it
On Thu, Jan 13, 2011 at 21:37, Tom Lane wrote:
> Robert Haas writes:
>> I strongly believe you're in the minority on that one, for the same
>> reasons that I don't think most people would agree with your notion of
>> what should be the default shutdown mode. A database that can't
>> accept new c
Robert Haas writes:
> I strongly believe you're in the minority on that one, for the same
> reasons that I don't think most people would agree with your notion of
> what should be the default shutdown mode. A database that can't
> accept new connections is a liability, not an asset.
Killing acti
Robert Haas wrote:
> A database that can't accept new connections is a liability, not
> an asset.
+1
I have so far been unable to imagine a use case for the production
databases I use where I would prefer to see backends continue after
postmaster failure.
-Kevin
--
Sent via pgsql-hackers
On Jan13, 2011, at 21:01 , Aidan Van Dyk wrote:
> On Thu, Jan 13, 2011 at 2:53 PM, Robert Haas wrote:
>> I'm not convinced. I was thinking that we could simply treat it like
>> SIGQUIT, if it's available. I doubt there's a real use case for
>> continuing to run queries after the postmaster and a
On Thu, Jan 13, 2011 at 3:01 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jan 13, 2011 at 2:45 PM, Tom Lane wrote:
>>> I wonder whether we could have some sort of latch-like counter that
>>> would count the number of active backends and deliver signals when the
>>> count went to zero. H
On Thu, Jan 13, 2011 at 2:53 PM, Robert Haas wrote:
> I'm not convinced. I was thinking that we could simply treat it like
> SIGQUIT, if it's available. I doubt there's a real use case for
> continuing to run queries after the postmaster and all the background
> processes are dead. Expedited de
Robert Haas writes:
> On Thu, Jan 13, 2011 at 2:45 PM, Tom Lane wrote:
>> I wonder whether we could have some sort of latch-like counter that
>> would count the number of active backends and deliver signals when the
>> count went to zero. However, if the goal is to defend against random
>> appli
On Thu, Jan 13, 2011 at 2:45 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jan 13, 2011 at 2:16 PM, Tom Lane wrote:
>>> Frankly I'd prefer to get rid of PostmasterIsAlive, not extend its use.
>>> It sucks because you don't get a signal on parent death. With the
>>> arrival of the latch c
Robert Haas writes:
> On Thu, Jan 13, 2011 at 2:16 PM, Tom Lane wrote:
>> Frankly I'd prefer to get rid of PostmasterIsAlive, not extend its use.
>> It sucks because you don't get a signal on parent death. With the
>> arrival of the latch code, having to check for PostmasterIsAlive
>> frequently
On Thu, Jan 13, 2011 at 2:16 PM, Tom Lane wrote:
> Frankly I'd prefer to get rid of PostmasterIsAlive, not extend its use.
> It sucks because you don't get a signal on parent death. With the
> arrival of the latch code, having to check for PostmasterIsAlive
> frequently is the only reason for an
David Fetter writes:
> I get that we can't prevent all pilot error, but I was hoping we could
> bullet-proof this a little more, especially in light of a certain
> extremely popular server OS's OOM killer's default behavior.
> Yes, I get that that behavior is crazy, and stupid, and that people
>
Florian Pflug writes:
> Couldn't normal backends call PostmasterIsAlive and exit if not, just
> like the startup process, the stats collector, autovacuum, bgwriter,
> walwriter, walreceiver, walsender and the wal archiver already do?
> I assumed they do, but now that I grepped the code it seems t
On Thu, Jan 13, 2011 at 12:45:07PM -0600, Kevin Grittner wrote:
> Tom Lane wrote:
>
> > I can't see automating it though. We already have a perfectly
> > good solution to the automated shutdown problem.
>
> Oh, I totally agree with that. I somehow thought we'd gotten off
> into how someone c
On Jan13, 2011, at 19:00 , Tom Lane wrote:
> At least on Unix I don't believe there is any other solution. You
> could try looking at ps output but there's a fundamental race condition,
> ie the postmaster could spawn another child just before you kill it,
> whereupon the child is reassigned to in
Tom Lane wrote:
> I can't see automating it though. We already have a perfectly
> good solution to the automated shutdown problem.
Oh, I totally agree with that. I somehow thought we'd gotten off
into how someone could recover after shooting their foot.
-Kevin
--
Sent via pgsql-hackers m
"Kevin Grittner" writes:
> Tom Lane wrote:
>> At least on Unix I don't believe there is any other solution. You
>> could try looking at ps output but there's a fundamental race
>> condition, ie the postmaster could spawn another child just before
>> you kill it, whereupon the child is reassigned
Tom Lane wrote:
> At least on Unix I don't believe there is any other solution. You
> could try looking at ps output but there's a fundamental race
> condition, ie the postmaster could spawn another child just before
> you kill it, whereupon the child is reassigned to init and there's
> no long
David Fetter writes:
> On Thu, Jan 13, 2011 at 10:41:28AM -0500, Tom Lane wrote:
>> It's just that you're then looking at having to manually clean up the
>> child processes and then restart the postmaster; a process that is not
>> only tedious but does offer the possibility of screwing yourself.
On Thu, Jan 13, 2011 at 10:41:28AM -0500, Tom Lane wrote:
> David Fetter writes:
> > I've noticed over the years that we give people dire warnings never to
> > send a KILL signal to the postmaster, but I'm unsure as to what are
> > potential consequences of this, as in just exactly how this can re
David Fetter writes:
> I've noticed over the years that we give people dire warnings never to
> send a KILL signal to the postmaster, but I'm unsure as to what are
> potential consequences of this, as in just exactly how this can result
> in problems. Is there some reference I can look to for exp
Folks,
I've noticed over the years that we give people dire warnings never to
send a KILL signal to the postmaster, but I'm unsure as to what are
potential consequences of this, as in just exactly how this can result
in problems. Is there some reference I can look to for explanations
of the mecha
45 matches
Mail list logo
