Re: foreign key locks, 2nd attempt

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
> <alvherre(at)commandprompt(dot)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 <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support