Re: smart shutdown at end of transaction (was: Default mode for shutdown)

On Sun, Apr 29, 2012 at 1:48 PM, Peter Eisentraut <peter_e(at)gmx(dot)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 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.
>
> Well, either there are possible incompatibilities, in which case users
> will be slow to adopt new releases, as is currently the case, or there
> strictly won't be any (unless hidden behind config settings or similar),
> but then introducing new features or bug fixes can take many years.  So
> far we've erred on the side of "progress".

"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, and one
I hope we won't repeat any time soon, but if you look through the
release notes for, say, 9.1, just about every "incompatibility" listed
there amounts to fixing something that was either demonstrably broken
or widely hated in prior releases. Turning on
standard_conforming_strings by default was a big deal, but we've been
phasing that change in for five years or so, so I think we really did
about as much to ease that transition as is humanly possible.
Moreover, you can always turn the GUC off again, if the new behaviour
is a problem.

The only way we're going to have fewer incompatibilities than we do
now is to preserve existing behavior even when it's broken,
widely-hated, and/or not standards-conformant. IMHO, that would be
taking a sound principle to an illogical extreme.

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