Re: foreign key locks, 2nd attempt

On Wed, Jan 18, 2012 at 05:18:31PM -0300, Alvaro Herrera wrote:
> Excerpts from Heikki Linnakangas's message of mar ene 17 03:21:28 -0300 2012:
> > On 16.01.2012 21:52, Alvaro Herrera wrote:
> > > I was initially thinking that pg_multixact should return the
> > > empty set if requested members of a multi that preceded the freeze
> > > point. That way, I thought, we would just never try to access a page
> > > originated in the older version (assuming the freeze point is set to
> > > "current" whenever pg_upgrade runs). However, as things currently
> > > stand, accessing an old multi raises an error. So maybe we need a
> > > scheme a bit more complex to handle this.
> >
> > Hmm, could we create new multixact files filled with zeros, covering the
> > range that was valid in the old cluster?
>
> Hm, we could do something like that I guess. I'm not sure that just
> zeroes is the right pattern, but it should be something simple.

PostgreSQL 9.1 can have all ~4B MultiXactId on disk at any given time.

We could silently ignore the lookup miss when HEAP_XMAX_LOCK_ONLY is also set.
That makes existing data files acceptable while still catching data loss
scenarios going forward. (It's tempting to be stricter when we know the
cluster data files originated in PostgreSQL 9.2+, but I'm not sure whether
that's worth its weight.)