Re: Prototype: In-place upgrade v02

Zdenek Kotala wrote:
> Tom Lane napsal(a):
>> Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
>>> In fact, I don't think there's any low-level data format changes yet
>>> between 8.3 and 8.4, so this would be a comparatively easy release to
>>> implement upgrade-in-place. There's just the catalog changes, but
>>> AFAICS nothing that would require scanning through relations.
>>
>> After a quick scan of the catversion.h changelog (which hopefully covers
>> any such changes): we changed sequences incompatibly, we changed hash
>> indexes incompatibly (even without the pending patch that would change
>> their contents beyond recognition), and Teodor did some stuff to GIN
>> indexes that might or might not represent an on-disk format change,
>> you'd have to ask him. We also whacked around the sort order of
>> bpchar_pattern_ops btree indexes.
>
> Hmm, It seems that reindex is only good answer on all these changes.

Isn't that exactly what we want to avoid with upgrade-in-place? As long
as the conversion can be done page-at-a-time, without consulting other
pages, we can do it when the page is read in.

I'm not sure what the GIN changes were, but I didn't see any changes to
the page layout at a quick glance.

The bpchar_pattern_ops change you mentioned must be this one:
> A not-immediately-obvious incompatibility is that the sort order within
> bpchar_pattern_ops indexes changes --- it had been identical to plain
> strcmp, but is now trailing-blank-insensitive. This will impact
> in-place upgrades, if those ever happen.

The way I read that, bpchar_pattern_ops just became less sensitive. Some
values are now considered equal that weren't before, and thus can now be
stored in any order. That's not an incompatible change, right?

> Sequence should be converted during catalog conversion.

Agreed.

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