Prev: [HACKERS] Did we really want to force an initdb in beta2?
Next: [pgsql-hackers] Daily digest v1.10705 (13 messages)
From: Heikki Linnakangas on 3 Jun 2010 11:25
On 03/06/10 17:54, Tom Lane wrote:
> Because that's the consequences of fooling with pg_control.
> I committed the PG_CONTROL_VERSION bump that was missing from
> the patch Robert committed last night, but I wonder whether
> we shouldn't revert the whole thing instead. It's not apparent
> to me that what it bought is worth forcing beta testers to initdb.

Hmph, good point, I did not think of that at all when I reviewed the patch.

If we moved the new DB_SHUTDOWNED_IN_RECOVERY as the last item in the
enum, we would stay backwards-compatible.

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Robert Haas on 3 Jun 2010 11:30
On Thu, Jun 3, 2010 at 11:25 AM, Heikki Linnakangas
<heikki.linnakangas(a)enterprisedb.com> wrote:
> On 03/06/10 17:54, Tom Lane wrote:
>>
>> Because that's the consequences of fooling with pg_control.
>> I committed the PG_CONTROL_VERSION bump that was missing from
>> the patch Robert committed last night, but I wonder whether
>> we shouldn't revert the whole thing instead.  It's not apparent
>> to me that what it bought is worth forcing beta testers to initdb.
>
> Hmph, good point, I did not think of that at all when I reviewed the patch.
>
> If we moved the new DB_SHUTDOWNED_IN_RECOVERY as the last item in the enum,
> we would stay backwards-compatible.

Ugh, sorry about that. I didn't realize this either.

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Tom Lane on 3 Jun 2010 12:16
Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.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.
The code would look mighty ugly in any case.

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

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Heikki Linnakangas on 3 Jun 2010 12:40
On 03/06/10 19:16, Tom Lane wrote:
> Heikki Linnakangas<heikki.linnakangas(a)enterprisedb.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

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Tom Lane on 3 Jun 2010 13:00
Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com> writes:
> On 03/06/10 19:16, Tom Lane wrote:
>> 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.

Maybe we should just get rid of the hint.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

 |  Next  |  Last
Pages: 1 2 3 4
Prev: [HACKERS] Did we really want to force an initdb in beta2?
Next: [pgsql-hackers] Daily digest v1.10705 (13 messages)