Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
The question is if we should do toast modification now to avoid
potential future problems or if we will solve it when any on-disk
format change requires it?
Perhaps we should just add the new attid attribute to the toast table,
but mark it as nullable? We wouldn't need to fill it in in the 8.3->8.4
conversion but new tuples would include it.
>
In the future release that we actually need it, we'll make it
non-nullable, and write a pre-upgrade script to retoast tuples that
don't have it yet.
Hmm, It seems to me as a good idea. It will complicated preupgrade script for
8.4->8.5 script but we will have one year to developed it :-).
What we need to do is during conversion to add nullbit array for each tuple in
toasttable. I think there is enough space on all platform to reuse gap between
tuple header and data.
Hmm. That would change TOAST_MAX_CHUNK_SIZE, though.
Yes, it change it. :(
but I can convert easily residx to offset end (residx*TOAST_MAX_CHUNK_SIZE -+
something) during page conversion.
I prefer do it now, because there could be small risk that it will not
possible to do it in the future. When in-place upgrade will be
implemented nobody will want to perform backup/restore.
I feel we should avoid doing anything extra, risking that we get nothing
finished.
Agree.
Zdenek
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
