Re: foreign key locks, 2nd attempt

Excerpts from Kevin Grittner's message of jue feb 23 13:31:36 -0300 2012:
>
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> wrote:
>
> > As for sanity -- I regard multixacts as a way to store extended
> > Xmax information. The original idea was obviously much more
> > limited in that the extended info was just locking info. We've
> > extended it but I don't think it's such a stretch.
>
> Since the limitation on what can be stored in xmax was the killer
> for Florian's attempt to support SELECT FOR UPDATE in a form which
> was arguably more useful (and certainly more convenient for those
> converting from other database products), I'm wondering whether
> anyone has determined whether this new scheme would allow Florian's
> work to be successfully completed. The issues seem very similar.
> If this approach also provides a basis for the other work, I think
> it helps bolster the argument that this is a good design; if not, I
> think it suggests that maybe it should be made more general or
> extensible in some way. Once this has to be supported by pg_upgrade
> it will be harder to change the format, if that is needed for some
> other feature.

I have no idea what improvements Florian was seeking, but multixacts now
have plenty of bit flag space to indicate whatever we want for each
member transaction, so most likely the answer is yes. However we need
to make clear that a single SELECT FOR UPDATE in a tuple does not
currently use a multixact; if we wish to always store flags then we are
forced to use one which incurs a performance hit.

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