>>>>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> I'm prepared to give slightly more consideration to option #3:
>> make the new code read the old format as well as the new one.
Tom> If you think you can make that work, it would solve the problem.
I was hoping to do it without changing the new format, but that turns
out not to be achievable, thanks to the fact (which I just discovered)
that the old hstore can leave unlimited amounts of wasted space at the
end of the object (does this count as a bug?).
It's doable via a small change to the new format of course. This would
require some care in handling the (few) users of pgfoundry hstore-new,
but all that means is that users of the pre-release hstore-new would
have to ensure at least one update of stored data before doing a binary
migrate to 8.5, which I think isn't too much of a burden.
The other option would be to fix the wasted-space bug in the existing
hstore, and document that stored data must be updated at least once
subsequent to that fix before doing a binary migrate to 8.5.
(The pathological case is _very_ rare, requiring an 0-length key with
exactly 32kb of data, followed by a specific series of key lengths
with values of length 1, and with more than 28kbytes of wasted space
at the end of the value, and only on little-endian machines. The only
way to get that much wasted space is to do several thousand iterations
of UPDATE ... SET hs = hs || ''; each of which adds 8 bytes of wasted
space to the end of the value. But even so, somebody, somewhere,
probably has a value that matches...)
In response to
pgsql-hackers by date
|Next:||From: David E. Wheeler||Date: 2009-07-22 16:13:39|
|Subject: Re: revised hstore patch|
|Previous:||From: Kevin Grittner||Date: 2009-07-22 15:25:42|
|Subject: Re: Higher TOAST compression.|