Re: smart shutdown at end of transaction (was: Default mode for shutdown) - Mailing list pgsql-hackers

On Sat, Apr 28, 2012 at 7:04 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On Fri, Apr 27, 2012 at 7:57 PM, Robert Haas <robertmhaas@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 behavior.  If we are not going to change the default behavior,
>> then there is zero point in talking about this.
>
> That doesn't follow.
>
> You are right to bring up this issue. Many people do think current
> "smart" mode is annoying, though we must accept that some people like
> it *and* that changing the default behaviour in one release is a bad
> thing.
>
> I don't think anyone has spoken against introducing a new mode. Having
> it is a good thing, whether or not it is default.
>
> 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 to phase in a change over a series of
releases, but I don't see how that would be possible here.  If we
intend ever to change the default mode, then we have to do it
sometime, and that release is going to have a backward-incompatibility
no matter which one it is.  Personally, as backward incompatibilities
go, I think this one is pretty minor.  Most people are probably
already using scripts that specify fast mode, and those scripts won't
change.  But even for people who actually are using smart mode, most
people do not shut down the database all that often, and it's rather
pessimistic to suppose that the proposed new mode will break anything
for them.  But even if it does, we can't make improvements to the
system without sometimes changing things in a backward-incompatible
way, and if we get into the mind-set that no amount of
backward-incompatibility is ever acceptable, we're going to seriously
limit our opportunities to revisit poor design decisions.

I think there's a funny kind of thing that happens when we discuss a
behavior that is sub-optimal: we start to look for ways to justify
leaving it the way it is, because surely it couldn't be a terrible
idea if it's been like that forever.  I think there's some of that
going on on the thread about stripping trailing null columns, too: if
we've got a benchmark result showing that the patch saves CPU time on
a 5-column table (!), then all the pontificating about 700-column
tables being rare is irrelevant.  Similarly here: it's true that
someone might have to revisit their init scripts, but should they fail
to do so, the consequences are really not that dire.

On the other hand, in PostgreSQL 8.4, we changed TRUNCATE to wipe out
the entire inheritance hierarchy instead of only the named table
(unless the new ONLY keyword was added).  This obviously has the
potential to be completely disastrous for someone with a very
particular usage pattern, but there was little discussion and everyone
basically said "yeah, we should go ahead and change that, despite the
small risk that someone will accidentally blow away a lot more data
than they intended".  Maybe there are more people using smart shutdown
than there are people truncating only the root of an inheritance
hierarchy, but nothing we're proposing to do here is going to
permanently erase anyone's data, either.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company