Re: foreign key locks, 2nd attempt

Excerpts from Heikki Linnakangas's message of mar ene 17 03:21:28 -0300 2012:
>
> On 16.01.2012 21:52, Alvaro Herrera wrote:
> >
> > Excerpts from Heikki Linnakangas's message of lun ene 16 16:17:42 -0300 2012:
> >>
> >> On 15.01.2012 06:49, Alvaro Herrera wrote:
> >>> - pg_upgrade bits are missing.
> >>
> >> I guess we'll need to rewrite pg_multixact contents in pg_upgrade. Is
> >> the page format backwards-compatible?
> >
> > It's not.
> >
> > I haven't worked out what pg_upgrade needs to do, honestly. I think we
> > should just not copy old pg_multixact files when upgrading across this
> > patch.
>
> Sorry, I meant whether the *data* page format is backwards-compatible?
> the multixact page format clearly isn't.

It's supposed to be, yes. The HEAP_XMAX_IS_NOT_UPDATE bit (now renamed)
was chosen so that it'd take the place of the old HEAP_XMAX_SHARE_LOCK
bit, so any pages with that bit set should continue to work similarly.
The other infomask bits I used were previously unused.

> > 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.

--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support