Re: Page-level version upgrade (was: Block-level CRC checks)

David Fetter wrote:
> > Right. There were two basic approaches to handling a patch that
> > would expand when upgraded to the new version --- either allow the
> > system to write the old format, or have a pre-upgrade script that
> > moved tuples so there was guaranteed enough free space in every page
> > for the new format. I think we agreed that the later was better
> > than the former, and it was easy because we don't have any need for
> > that at this time. Plus the script would not rewrite every page,
> > just certain pages that required it.
>
> Please forgive me for barging in here, but that approach simply is
> untenable if it requires that the database be down while those pages
> are being found, marked, moved around, etc.
>
> The data volumes that really concern people who need an in-place
> upgrade are such that even
>
> dd if=$PGDATA of=/dev/null bs=8192 # (or whatever the optimal block size would be)
>
> would require *much* more time than such people would accept as a down
> time window, and while that's a lower bound, it's not a reasonable
> lower bound on the time.

Well, you can say it is unacceptable, but if there are no other options
then that is all we can offer. My main point is that we should consider
writing old format pages only when we have no choice (page size might
expand), and even then, we might decide to have a pre-migration script
because the code impact of writing the old format would be too great.
This is all hypothetical until we have a real use-case.

> If this re-jiggering could kick off in the background at start and
> work on a running PostgreSQL, the whole objection goes away.
>
> A problem that arises for any in-place upgrade system we do is that if
> someone's at 99% storage capacity, we can pretty well guarantee some
> kind of catastrophic failure. Could we create some way to get an
> estimate of space needed, given that the system needs to stay up while
> that's happening?

Yea, the database would expand and hopefully have full transaction
semantics.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +