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

On Sun, Apr 29, 2012 at 12:41 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Sat, Apr 28, 2012 at 7:04 AM, Simon Riggs <simon@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.
>
> 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.

I don't think you can use the TRUNCATE case as an example. For me,
that was a prime case of insufficient discussion around the principle
of backwards compatibility. It wasn't clear to me that was happening
and had I known, I would have objected. IIRC the first I knew of it
was when the release notes came out months after things were settled.

We go to great lengths to note initdb inducing behaviour during beta,
but very little towards behaviour changes that require downstream
software changes.

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 open items wiki, so that people
listening can see what might happen and get a chance to object. Or if
changes do go ahead, at least we give them a few months warning to
change the downstream software. Otherwise all that happens is our new
release comes out and fewer people use it because it takes ages to
actually realign the software stack enough for our software to be
used.

The better we succeed at persuading the world to use Postgres the more
important backwards compatibility becomes. When fewer people used
Postgres it was easy to charge forwards aggressively, but as we begin
to lead we must be more careful.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services