Re: Prototype: In-place upgrade v02

Zdenek Kotala wrote:
> Tom Lane napsal(a):
>> Heikki Linnakangas <heikki.linnakangas@enterprisedb.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