Excerpts from Tom Lane's message of mié dic 01 14:44:03 -0300 2010:
> Florian Pflug <fgp@phlo.org> writes:
> > On Dec1, 2010, at 17:17 , Tom Lane wrote:
> >> There's not enough space in the infomask to record which columns (or
> >> which unique index) are involved. And if you're talking about data that
> >> could remain on disk long after the unique index is gone, that's not
> >> going to be good enough.
>
> > We'd distinguish two cases
> > A) The set of locked columns is a subset of the set of columns mentioned in
> > *any* unique index. (In other words, for every locked column there is a
> > unique index which includes that column, though not necessarily one index
> > which includes them all)
> > B) The set of locked columns does not satisfy (A)
>
> How's that fix it? The on-disk flags are still falsifiable by
> subsequent index changes.
>
> > Creating indices shouldn't pose a problem, since it would only enlarge the set of locked columns for rows with
HEAP_XMAX_SHARED_LOCK_KEYset.
>
> Not with that definition. I could create a unique index that doesn't
> contain some column that every previous unique index contained.
This is not a problem, because a later UPDATE that tried to modify a
locked tuple on a column only indexed by the new index, would consider
it locked. Which is OK. There would only be a problem if we were
allowed to drop an index (which would reduce the set of locked columns),
but we don't allow this because DROP INDEX requires an exclusive lock on
the table and thus there cannot be anyone with key-locked tuples in it.
AFAICT Florian's definition is good.
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support