Tom Lane napsal(a):
Zdenek Kotala <[EMAIL PROTECTED]> writes:
Attached patch allows to setup storage parameter for space
reservation.
What is the point of this? We don't need it for 8.3->8.4, we aren't
going to back-patch such a thing into 8.2 or before (certainly not
before, since reloptions didn't exist before 8.2), and I would hope we
put in a more general solution than this for 8.4-to-later preparatory
fixes.
There is whole idea.
By my opinion the space reservation is possible to split into three separate
problems:
1) First mandatory is to implement space reservation functionality in the core.
It is what this patch tries to do. It prevents to store new data in reserved
area. The configuration is implemented with reloptions.
I think This part is possible simply backported back to 8.2 and it allows
in-place online upgrade form 8.2 to 8.4 (and indirectly from 8.1). There is only
limitation for toasted arrays and composite datatypes, which can be solve with
offline conversion.
How Jim Nasby mentioned we need to add also per tuple space reservation which is
not required for V3->V4 upgrade or it is negative, but it is important to have
it for 8.4, because who know what will happen int 8.5 development.
By my opinion, this functionality is similar to fillfactor and it is
independent. And can be committed separately.
2) Second part is pre-upgrade check/preparation process. For 8.2 it has to be
store procedure which will work separately (no core changes). In 8.4 it will be
implemented into core - new column in pg_class and pg_database. Vacuum adjusting
and so on.
3) Last part is pre-upgrade configuration which correctly setup reserved space
all non-system relations in database cluster.
Thats my idea. Let me know any comments.
Thanks Zdenek
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
