On Tue, May 8, 2012 at 12:59 AM, Robert Haas wrote:
> On Sat, May 5, 2012 at 12:41 PM, Fujii Masao wrote:
>> On Sat, Apr 28, 2012 at 4:00 AM, Robert Haas wrote:
>>> On Fri, Apr 27, 2012 at 2:48 PM, Tom Lane wrote:
I'm not necessarily opposed to commandeering the name "smart" for the
n
On Sat, May 5, 2012 at 12:41 PM, Fujii Masao wrote:
> On Sat, Apr 28, 2012 at 4:00 AM, Robert Haas wrote:
>> On Fri, Apr 27, 2012 at 2:48 PM, Tom Lane 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
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 exis
On Sat, Apr 28, 2012 at 4:00 AM, Robert Haas wrote:
> On Fri, Apr 27, 2012 at 2:48 PM, Tom Lane 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 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 thi
On Mon, Apr 30, 2012 at 9:55 AM, Wolfgang Wilhelm
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 normal" and "s
and "shutdown transactional".
Wolfgang
Von: Tom Lane
An: Simon Riggs
CC: Robert Haas ; Alvaro Herrera
; Magnus Hagander ;
PostgreSQL-development
Gesendet: 20:48 Freitag, 27.April 2012
Betreff: Re: [HACKERS] smart shutdown at end of transaction (was: Default mode
for shutdo
Tom Lane wrote:
>> On Fri, Apr 27, 2012 at 7:29 PM, Tom Lane 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
with
>>> ta
On Sun, Apr 29, 2012 at 5:27 PM, Tom Lane wrote:
> Robert Haas 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).
Robert Haas 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 first magnitude, an
On Sun, Apr 29, 2012 at 1:48 PM, Peter Eisentraut 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 called "
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
On Sun, Apr 29, 2012 at 5:41 PM, Tom Lane wrote:
> Simon Riggs 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 irrele
Simon Riggs 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
> transactions, I
On Sun, Apr 29, 2012 at 4:06 PM, Tom Lane wrote:
> Peter Eisentraut 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
>> k
Peter Eisentraut 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 the current
Peter Eisentraut 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 prepared tr
On Sun, Apr 29, 2012 at 12:41 AM, Robert Haas wrote:
> On Sat, Apr 28, 2012 at 7:04 AM, Simon Riggs 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.
>
> In some cases, there are ways t
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 lör, 2012-04-28 at 11:12 -0400, Tom Lane wrote:
> Peter Eisentraut 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 a
On Sat, Apr 28, 2012 at 7:04 AM, Simon Riggs wrote:
> On Fri, Apr 27, 2012 at 7:57 PM, 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 ar
Peter Eisentraut 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 its
>> not
On Fri, Apr 27, 2012 at 8:36 PM, Heikki Linnakangas
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 "smart")
> wait transact
On Fri, Apr 27, 2012 at 7:57 PM, 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 fre, 2012-04-27 at 18:09 -0400, Tom Lane wrote:
> Robert Haas 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
> > -> immed
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 prepar
Robert Haas 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 -> smart, SIGINT ->
On Fri, Apr 27, 2012 at 1:57 PM, 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.
count me i
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 sh
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 o
Heikki Linnakangas 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 bounded time, it would also be nice to
On Fri, Apr 27, 2012 at 3:00 PM, Robert Haas wrote:
> On Fri, Apr 27, 2012 at 2:48 PM, Tom Lane 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 27.04.2012 21:56, Tom Lane wrote:
Magnus Hagander writes:
On Fri, Apr 27, 2012 at 20:48, Tom Lane 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- al
On Fri, Apr 27, 2012 at 2:48 PM, Tom Lane 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")
> s
On Fri, Apr 27, 2012 at 2:29 PM, Tom Lane 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 happy wi
Magnus Hagander writes:
> On Fri, Apr 27, 2012 at 20:48, Tom Lane 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
On Fri, Apr 27, 2012 at 20:48, Tom Lane wrote:
> Simon Riggs writes:
>> On Fri, Apr 27, 2012 at 7:29 PM, Tom Lane 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
Simon Riggs writes:
> On Fri, Apr 27, 2012 at 7:29 PM, Tom Lane 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 with
>> ta
On Friday, April 27, 2012 08:38:10 PM Simon Riggs wrote:
> On Fri, Apr 27, 2012 at 7:29 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> On Wed, Dec 15, 2010 at 10:11 AM, Alvaro Herrera
> >>
> >> wrote:
> >>> It occurs to me that we may need a new mode, which disconnects sessions
> >>> that are
Hi,
On Friday, April 27, 2012 07:42:59 PM Robert Haas wrote:
> On Wed, Dec 15, 2010 at 10:11 AM, Alvaro Herrera
> 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 a
On Fri, Apr 27, 2012 at 7:29 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Dec 15, 2010 at 10:11 AM, Alvaro Herrera
>> 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 t
Robert Haas writes:
> On Wed, Dec 15, 2010 at 10:11 AM, Alvaro Herrera
> 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 alone; this could be the new default. Of
>>
On Fri, Apr 27, 2012 at 1:46 PM, Magnus Hagander wrote:
> On Fri, Apr 27, 2012 at 19:42, Robert Haas wrote:
>> On Wed, Dec 15, 2010 at 10:11 AM, Alvaro Herrera
>> 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 t
On Fri, Apr 27, 2012 at 19:42, Robert Haas wrote:
> On Wed, Dec 15, 2010 at 10:11 AM, Alvaro Herrera
> 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 alone; this cou
On Wed, Dec 15, 2010 at 10:11 AM, Alvaro Herrera
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 alone; this could be the new default. Of
> course, this is much more dif
45 matches
Mail list logo
