Re: Did we really want to force an initdb in beta2?

On 03/06/10 19:16, Tom Lane wrote:
> Heikki Linnakangas<heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
>> If we moved the new DB_SHUTDOWNED_IN_RECOVERY as the last item in the
>> enum, we would stay backwards-compatible.
>
> I don't think that's a terribly workable idea; the enum is laid out so
> that inequality tests are sensible, and I'm not sure there aren't any.

Hmm, the only inequality tests on that field I can see check that the
value is valid, i.e between the first and last valid value.

> The code would look mighty ugly in any case.

True.

One more hacky idea: Keep the code as it is and change pg_control
version back to what it was in beta1. Add a note in the release notes
that if you're upgrading from beta1, you must shut down the database
cleanly first. When you do that, control file is in DB_SHUTDOWNED state,
and the enum value for that did not change.

One caveat is that a standby server will be DB_IN_ARCHIVE_RECOVERY,
which did change value so that with beta2 binaries it will look like
DB_IN_CRASH_RECOVERY. I think that would still work, though (and if not,
in the worst case you'll just have to reinitialize the standby from a
new base backup).

> What exactly was the reason for this patch? Could it be held over till
> 9.1?

Before the patch, when you shut down a standby server, you get this
message in the log on the next startup:

LOG: database system was interrupted while in recovery at log time
2010-06-02 14:48:28 EEST
HINT: If this has occurred more than once some data might be corrupted
and you might need to choose an earlier recovery target.

The problem is that that hint is pretty alarming. The data should be
fine if the standby server was shut down cleanly with pg_ctl stop -m
fast/smart.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com