Re: serializable lock consistency - Mailing list pgsql-hackers

On Dec21, 2010, at 00:08 , Robert Haas wrote:
> My previously expressed concern about (C) wasn't based on ugliness,
> but rather on my believe that there is likely a whole lot of code
> which relies on the CTID being a self-link when no UPDATE has
> occurred.  We'd have to be confident that all such cases had been
> found and fixed, which might not be easy to be confident about.

Thats certainly a valid concern, and one that a credible proposal
will have to address. 

> The obvious question is - if we can overlay CTID in some
> situations, is there a better use for that than this?  Just to throw
> out something that might be totally impractical, maybe we could get
> rid of XMAX.  If the tuple hasn't been updated, the CTID field stores
> the XMAX; if it HAS been updated, the CTID points to the successor
> tuple, whose XMIN is our XMAX.  I'm sure there are a bunch of reasons
> why that doesn't actually work - I can think of some of them myself -
> but the point is that there's an opportunity cost to stealing those
> bits.  Once they're dedicated to this purpose, they can't ever be
> dedicated to any other purpose.

Yes, there is an opportunity cost there, I can't argue with that.

> Space in the tuple header is
> precious, and I am not at all convinced that we should be willing to
> surrender any for this.

Thats a pretty tight space to maneuver in, though. So tight, in fact,
that I may as well give up, barring some absolutely genius idea, which
I don't even know where to look for at the moment.

Every feature has its price, and if giving up on completely hypothetical
future savings is too costly, then surely anything else I might suggest
is too :-(

> We have to believe not only that this change
> is good, but also that it's more good than some other purpose to which
> that bit space could potentially be put.

Unfortunately, I'm running out of arguments for why *is* important
and *is* worth paying a price. I've been forced to simply give up on
making some database-side constraint enforcement 100% waterproof in
the past. That bugged me greatly each time, and each time weakened
my case when I tried to explain to client why enforcing such things
in the database is a Good Thing. I therefore have a hard time trying
to understand why people mostly seem to regard this is a non-issue
or merely a nice-to-have. Regarding the sub-transaction vs. locking
issue -  I haven't been bitten by this personally, since I tend to
avoid using sub-transactions at all. But if I did, I'd feel even
stronger about this, since it's clearly a bug.

best regards,
Florian Pflug