Re: Remaining beta blockers

On Sat, Apr 27, 2013 at 10:59:32AM -0400, Tom Lane wrote:
> The schedule says we're going to wrap 9.3beta1 on Monday, but it doesn't
> feel to me like we are anywhere near ready to ship a credible beta.
> Of the items on the 9.3 open-items page,
> https://wiki.postgresql.org/wiki/PostgreSQL_9.3_Open_Items
> there are at least three that seem like absolute drop-dead stop-ship issues:

> 1. The matviews mess.  Changing that will force initdb, more than
> likely, so we need it resolved before beta1.

In similar discussions last year, we concluded that forcing initdb after beta
is fine so long as pg_upgrade can handle the change.  Any of the proposals for
changing materialized view scannability are easy for pg_upgrade to handle.

> As far as #1 goes, I think we have little choice at this point but to
> remove the unlogged-matviews feature for 9.3.  Various alternatives were
> kicked around in the "matview scannability rehash" thread but they were
> only marginally less klugy, and nobody's stepped up with a patch anyway.
> I will undertake to remove unlogged matviews and replace isscannable-
> as-a-file-size-property with isscannable-as-a-reloption (unless anyone
> feels it would be better as a separate pg_class column?).

This perspective is all wrong.  I hate to be blunt, but that thread ended with
your technical objections to the committed implementation breaking apart and
sinking.  There was no consensus to change it on policy/UI grounds, either.

> 2. The checksum algorithm business.  Again, we don't get to tinker with
> that anymore once we're in beta.

Since pg_upgrade isn't in a position to migrate beta clusters to a new
checksum algorithm, I share the desire to settle this sooner rather than
later.  However, if finalizing it before beta singularly entails slipping beta
by more than a week or two, I think we should cut the beta without doing so.
Then mention in its release notes that "initdb --data-checksums" beta clusters
may require dump/reload to upgrade to a release or later beta.

> Anything else that's "must fix"?

Not to my knowledge.

nm

-- 
Noah Misch
EnterpriseDB                                 http://www.enterprisedb.com