On Tue, May 8, 2012 at 12:59 AM, Robert Haas robertmh...@gmail.com wrote:
On Sat, May 5, 2012 at 12:41 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Sat, Apr 28, 2012 at 4:00 AM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Apr 27, 2012 at 2:48 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm
Fujii Masao wrote:
I'm not necessarily opposed to commandeering the name smart for the
new behavior, so that what we have to find a name for is the old smart
behavior. How about
slow - allow existing sessions to finish (old smart)
smart - allow existing transactions to
On Sat, May 5, 2012 at 12:41 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Sat, Apr 28, 2012 at 4:00 AM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Apr 27, 2012 at 2:48 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm not necessarily opposed to commandeering the name smart for the
new
On Sat, Apr 28, 2012 at 4:00 AM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Apr 27, 2012 at 2:48 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm not necessarily opposed to commandeering the name smart for the
new behavior, so that what we have to find a name for is the old smart
behavior.
On Sun, Apr 29, 2012 at 10:19:38AM +0100, Simon Riggs wrote:
Maybe we don't need to do this over multiple releases, but we do need
to give warning of possible incompatibilities. It would be good to see
a specific post on hackers called Planned Incompatibilities in 9.2,
or collect such things
Tom Lane wrote:
On Fri, Apr 27, 2012 at 7:29 PM, Tom Lane t...@sss.pgh.pa.us wrote:
No, I'm not happy with that. Smart shutdown is defined to not
affect
current sessions. I'm fine with having a fourth mode that acts as
you
suggest (and, probably, even with making it the default); but not
: [HACKERS] smart shutdown at end of transaction (was: Default mode
for shutdown)
Simon Riggs si...@2ndquadrant.com writes:
On Fri, Apr 27, 2012 at 7:29 PM, Tom Lane t...@sss.pgh.pa.us wrote:
No, I'm not happy with that. Smart shutdown is defined to not affect
current sessions. I'm fine
On Mon, Apr 30, 2012 at 9:55 AM, Wolfgang Wilhelm
wolfgang20121...@yahoo.de wrote:
Just for the ones interested in a view on another turf:
In Oracle shutdown immediate is the fastest _clean_ shutdown and shutdown
abort is equal to shutdown immediate in PG.
The other modes are called shutdown
On lör, 2012-04-28 at 11:12 -0400, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
On fre, 2012-04-27 at 22:30 +0200, Andres Freund wrote:
In the few cases where I investigated it TMs don't use transactions
themselves (which I think is correct, they don't need them), so
On fre, 2012-04-27 at 14:57 -0400, Robert Haas wrote:
I think there is no point at all in having a discussion about this
unless we can first agree that the overwhelming majority of people who
have commented on this issue on this list are unhappy with the current
default behavior. If we are
On Sun, Apr 29, 2012 at 12:41 AM, Robert Haas robertmh...@gmail.com wrote:
On Sat, Apr 28, 2012 at 7:04 AM, Simon Riggs si...@2ndquadrant.com wrote:
So lets implement the new shutdown mode and work out a transition path
to a new default. Changing rapidly screws up the people we love the
most.
Peter Eisentraut pete...@gmx.net writes:
In any case, if either the existing session of the TM is cut or it
cannot create a new connection, it will, after some time, have to give
up roll back the prepared transactions on the other servers. So some
kind of setting to not shut down if there are
Peter Eisentraut pete...@gmx.net writes:
On fre, 2012-04-27 at 14:57 -0400, Robert Haas wrote:
I think there is no point at all in having a discussion about this
unless we can first agree that the overwhelming majority of people who
have commented on this issue on this list are unhappy with
On Sun, Apr 29, 2012 at 4:06 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Eisentraut pete...@gmx.net writes:
In any case, if either the existing session of the TM is cut or it
cannot create a new connection, it will, after some time, have to give
up roll back the prepared transactions on the
Simon Riggs si...@2ndquadrant.com writes:
I think we only need one new mode, shutdown when transactions are
finished should only shutdown when all types of transaction are
complete. For people that don't use prepared transactions the
difference is irrelevant. For people that do use prepared
On Sun, Apr 29, 2012 at 5:41 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
I think we only need one new mode, shutdown when transactions are
finished should only shutdown when all types of transaction are
complete. For people that don't use prepared
On sön, 2012-04-29 at 10:19 +0100, Simon Riggs wrote:
Maybe we don't need to do this over multiple releases, but we do need
to give warning of possible incompatibilities. It would be good to see
a specific post on hackers called Planned Incompatibilities in 9.2,
or collect such things on the
On Sun, Apr 29, 2012 at 1:48 PM, Peter Eisentraut pete...@gmx.net wrote:
On sön, 2012-04-29 at 10:19 +0100, Simon Riggs wrote:
Maybe we don't need to do this over multiple releases, but we do need
to give warning of possible incompatibilities. It would be good to see
a specific post on hackers
Robert Haas robertmh...@gmail.com writes:
Erred on the side of progress might even be a little strong, because
I think for the most part we have been extremely judicious about
backward incompatibilities in the last few releases (which is a good
thing). Obviously, 8.3 was a flag day of the
On Sun, Apr 29, 2012 at 5:27 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Erred on the side of progress might even be a little strong, because
I think for the most part we have been extremely judicious about
backward incompatibilities in the last few
On fre, 2012-04-27 at 22:30 +0200, Andres Freund wrote:
In the few cases where I investigated it TMs don't use transactions
themselves (which I think is correct, they don't need them), so
terminating any idle session - which the TM would appear as, as its
not using txns - would leave prepared
On fre, 2012-04-27 at 18:09 -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
It seems we need another signal for the new mode, and the obvious
candidate is SIGUSR2. But what shall the mapping look like?
[Choice #1] SIGUSR2 - slow, SIGTERM - smart, SIGINT - fast, SIGQUIT
On Fri, Apr 27, 2012 at 7:57 PM, Robert Haas robertmh...@gmail.com wrote:
I think there is no point at all in having a discussion about this
unless we can first agree that the overwhelming majority of people who
have commented on this issue on this list are unhappy with the current
default
On Fri, Apr 27, 2012 at 8:36 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
All the modes indeed wait (except for immediate), so I think it would make
sense to define the modes in terms of *what* they wait for.
wait sessions - allow existing sessions to finish (old
Peter Eisentraut pete...@gmx.net writes:
On fre, 2012-04-27 at 22:30 +0200, Andres Freund wrote:
In the few cases where I investigated it TMs don't use transactions
themselves (which I think is correct, they don't need them), so
terminating any idle session - which the TM would appear as, as
On Sat, Apr 28, 2012 at 7:04 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Fri, Apr 27, 2012 at 7:57 PM, Robert Haas robertmh...@gmail.com wrote:
I think there is no point at all in having a discussion about this
unless we can first agree that the overwhelming majority of people who
have
On Fri, Apr 27, 2012 at 19:42, Robert Haas robertmh...@gmail.com wrote:
On Wed, Dec 15, 2010 at 10:11 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
It occurs to me that we may need a new mode, which disconnects sessions
that are not in a transaction (or as soon as they are) but leaves
On Fri, Apr 27, 2012 at 1:46 PM, Magnus Hagander mag...@hagander.net wrote:
On Fri, Apr 27, 2012 at 19:42, Robert Haas robertmh...@gmail.com wrote:
On Wed, Dec 15, 2010 at 10:11 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
It occurs to me that we may need a new mode, which disconnects
Robert Haas robertmh...@gmail.com writes:
On Wed, Dec 15, 2010 at 10:11 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
It occurs to me that we may need a new mode, which disconnects sessions
that are not in a transaction (or as soon as they are) but leaves
in-progress transactions
On Fri, Apr 27, 2012 at 7:29 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Dec 15, 2010 at 10:11 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
It occurs to me that we may need a new mode, which disconnects sessions
that are not in a
Hi,
On Friday, April 27, 2012 07:42:59 PM Robert Haas wrote:
On Wed, Dec 15, 2010 at 10:11 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
It occurs to me that we may need a new mode, which disconnects sessions
that are not in a transaction (or as soon as they are) but leaves
On Friday, April 27, 2012 08:38:10 PM Simon Riggs wrote:
On Fri, Apr 27, 2012 at 7:29 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Dec 15, 2010 at 10:11 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
It occurs to me that we may need a
Simon Riggs si...@2ndquadrant.com writes:
On Fri, Apr 27, 2012 at 7:29 PM, Tom Lane t...@sss.pgh.pa.us wrote:
No, I'm not happy with that. Smart shutdown is defined to not affect
current sessions. I'm fine with having a fourth mode that acts as you
suggest (and, probably, even with making it
On Fri, Apr 27, 2012 at 20:48, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
On Fri, Apr 27, 2012 at 7:29 PM, Tom Lane t...@sss.pgh.pa.us wrote:
No, I'm not happy with that. Smart shutdown is defined to not affect
current sessions. I'm fine with having a fourth
Magnus Hagander mag...@hagander.net writes:
On Fri, Apr 27, 2012 at 20:48, Tom Lane t...@sss.pgh.pa.us wrote:
I'm not necessarily opposed to commandeering the name smart for the
new behavior, so that what we have to find a name for is the old smart
behavior. How about
slow-
On Fri, Apr 27, 2012 at 2:29 PM, Tom Lane t...@sss.pgh.pa.us wrote:
This idea appeared to have some support. I'd like to suggest that we
take this a step further. Instead of adding a fourth mode, I'd like
to suggest that we redefine smart to have the behavior described
above.
No, I'm not
On Fri, Apr 27, 2012 at 2:48 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm not necessarily opposed to commandeering the name smart for the
new behavior, so that what we have to find a name for is the old smart
behavior. How about
slow - allow existing sessions to finish (old smart)
On 27.04.2012 21:56, Tom Lane wrote:
Magnus Hagandermag...@hagander.net writes:
On Fri, Apr 27, 2012 at 20:48, Tom Lanet...@sss.pgh.pa.us wrote:
I'm not necessarily opposed to commandeering the name smart for the
new behavior, so that what we have to find a name for is the old smart
On Fri, Apr 27, 2012 at 3:00 PM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Apr 27, 2012 at 2:48 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm not necessarily opposed to commandeering the name smart for the
new behavior, so that what we have to find a name for is the old smart
behavior.
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote:
Just thinking out loud here..
In the spirit of kicking around ideas...
For those writing service scripts where you want a time limit on how
long a stop can take, so that the service script doesn't prevent OS
shutdown within a
On fre, 2012-04-27 at 20:39 +0200, Andres Freund wrote:
I think the current smart mode is rather useful. There is quite some
stuff that you cannot do inside a transaction - or it doesn't make
sense - which still needs to shutdown gracefully. E.g. transaction
managers.
Could you elaborate on
On Friday, April 27, 2012 10:17:59 PM Peter Eisentraut wrote:
On fre, 2012-04-27 at 20:39 +0200, Andres Freund wrote:
I think the current smart mode is rather useful. There is quite some
stuff that you cannot do inside a transaction - or it doesn't make
sense - which still needs to shutdown
On Fri, Apr 27, 2012 at 1:57 PM, Robert Haas robertmh...@gmail.com wrote:
I think there is no point at all in having a discussion about this
unless we can first agree that the overwhelming majority of people who
have commented on this issue on this list are unhappy with the current
default
Robert Haas robertmh...@gmail.com writes:
It seems we need another signal for the new mode, and the obvious
candidate is SIGUSR2. But what shall the mapping look like?
[Choice #1] SIGUSR2 - slow, SIGTERM - smart, SIGINT - fast, SIGQUIT
- immediate
[Choice #2] SIGTERM - slow, SIGUSR2 -
44 matches
Mail list logo
