I attach In-Place upgrade project concept. Any technical details about implementation of each part will be sent later (after concept acceptance).


        Please, let me know your comments.

                thanks Zdenek
In-place Upgrade project
---------------

Overview
--------
PostgreSQL community releases new version of PostgreSQL at least once a year 
but the released version is not able to run with old data files. For a user who 
wants to upgrade his database server is a nightmare to upgrade bigger database 
and it is impossible to upgrade a very large database. This project will try to 
solve this issue and provide a functionality for PostgreSQL which will cover 
all user's requirements.


Current status
--------------
1) Data upgrade is supported only by exporting and importing data using pg_dump
   - slow and causes a long downtime
   - extra disk space needed
   - require both version (old&new)
2) pg_migrator
   - faster then 1) but it still has a long downtime when on disk structure has 
changed
   - previous version of PostgreSQL is needed.
   - no downgrade
   - require both version (old&new)


Project Goals
-----
1) Minimize the database downtime.
2) Do not require extra disk space.
3) Do not require an old version of PostgreSQL to be installed.
4) Allow a fallback to original PostgreSQL version if something would go wrong.
5) Support all data types, including user defined types
6) Should be easy to use.


Functional specification
----------------
There might be more different approaches on how to perform upgrade. We assume 
that we need to convert a very big database. If we will upgrade the data files 
offline the database downtime might be critical. We will better  try to convert 
data online. This will bring a requirement that new major version of PostgreSQL 
must understand the old data structures and it must be able to work with them.

The next important requirement is an ability to fallback (downgrade) to the 
previous PostgreSQL version. When new major version does not work well for the 
user, he needs to be able to go back to the previous version with minimal 
downtime. This will bring a requirement that PostgreSQL should also be able to 
write data in the old format. However, we might expect some performance penalty.

The above requirements lead to PostgreSQL running in three modes:

compatibility mode (compat) - a new version is running on the old data files. 
It is possible to read and write data as in a previous version. Features of a 
new version might not be available. Fallback to the previous version is 
possible.

upgrade mode - a conversion of data files is running in the background. 
PostgreSQL have to be able to work with both the new data file format and the 
old data file format. Features of a new version might not be available. 
PostgreSQL have to be able to recover and continue in the upgrade mode in case 
of a power/system failure. Fallback to the previous version is not possible.

normal mode - all required data files were upgraded to the new format. Features 
of a new version are available. Fallback to the previous version is not 
possible.

Project Roadmap
-------------
1) Create a detailed design for each affected part
2) Design a testing environment/process
3) Implementation
4) Change development/release processes - patch author have to be responsible 
for providing the required upgrade operations/functions. Some more development 
related to upgrade might be done also after feature freeze. In-place upgrade 
should be available since x.y.1 version.


List of affected parts
----------------------

1) Data Page Structure
1.1) Page Layout
1.2) Tuple header and structure
1.3) Data encoding - data type changes
2) Control File
3) WAL
4) Catalog
5) Configuration files
7) Others (Procedure language, Communication protocol ...)


---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Reply via email to