Excerpts from Simon Riggs's message of jue feb 23 12:12:13 -0300 2012: > On Thu, Feb 23, 2012 at 3:04 PM, Alvaro Herrera > <alvhe...@commandprompt.com> wrote:
> > Sure. The problem is that we are allowing updated rows to be locked (and > > locked rows to be updated). This means that we need to store extended > > Xmax information in tuples that goes beyond mere locks, which is what we > > were doing previously -- they may now have locks and updates simultaneously. > OK, thanks. > > So why do we need pg_upgrade support? Two reasons. One is that in upgrades from a version that contains this patch to another version that also contains this patch (i.e. future upgrades), we need to copy the multixact files from the old cluster to the new. The other is that in upgrades from a version that doesn't contain this patch to a version that does, we need to set the multixact limit values so that values that were used in the old cluster are returned as empty values (keeping the old semantics); otherwise they would cause errors trying to read the member Xids from disk. > If pg_multixact is not persistent now, surely there is no requirement > to have pg_upgrade do any form of upgrade? The only time we'll need to > do this is from 9.2 to 9.3, which can of course occur any time in next > year. That doesn't sound like a reason to block a patch now, because > of something that will be needed a year from now. I think there's a policy that we must allow upgrades from one beta to the next, which is why Noah says this is a blocker starting from beta2. The pg_upgrade code for this is rather simple however. There's no rocket science there. -- Álvaro Herrera <alvhe...@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
