On Thu, Oct 21, 2010 at 7:24 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Would we be willing to make such assumptions to
> support in-place upgrade of timestamps?
>
If something like that is true (I'm not sure it is) then we could
consider doing the equivalent of what we were talking about doing for
changes that require more space in the new version.
1. Backpatch a change that refuses to create new values of the prohibited type
2. Provide a tool which scans all the values in your old database and
ensures there are no values of the prohibited type
3. Only allow pg_migrator from the version that includes the backpatched check
We would also have to make sure the new version's integer timestamp
doesn't write out any instances that look valid float timestamps. We
could have a guc to disable this check if you have a tool that scans
all the pages and rewrites any old values.
I think #1 would be feasible if it's really as simple as checking the
high bit which I imagine is what you're hoping it is. I supose it
would require writing out a 0 or larger denormalized value which would
mean we wouldn't be able to handle values close to the epoch properly.
I suppose for timestamps that doesn't really matter since that's
precision we never really have anyways.
I'm not sure if the tool to rewrite all existing values is so feasible
though. Considering that the values could be stuck in the middle of
arrays or records or even custom data types. Also there's tintervals
and so on to worry about too.
--
greg
