From: | Florian Pflug <fgp(at)phlo(dot)org> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: serializable lock consistency |
Date: | 2010-12-21 00:19:57 |
Message-ID: | 1DB62900-B7A9-45A8-85DE-6E686C1B4252@phlo.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2010-12-21 00:51:36 | Re: pg_ctl and port number detection |
Previous Message | Itagaki Takahiro | 2010-12-20 23:31:59 | Re: Extensions, patch v20 (bitrot fixes) |