Tom Lane wrote:
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
Sounds good, if we decide to go with the transient XID idea. So below
for an alternative that I just came up with.
This proposal appears to require taking and releasing a brand-new lock
type every time a snapshot is made or destroyed. That is certainly not
going to be less overhead than the transient-XID scheme. At least in
READ COMMITTED mode, there are normally multiple snapshots taken per
transaction.
Only for the serializable shapsnot I'd have thought, making the overhead
bearable (it's is surely the oldest of all the xact's shapshots) but ...
(Something worth noting here is that I expect soon, probably 8.4,
we will fix things so that what a backend advertises in MyProc->xmin
is the xmin of its oldest still-live snapshot. That means that xmin
will change intra-transaction in READ COMMITTED mode, and thus that
we would indeed need to take and release the sort of lock you are
suggesting each time.)
... with this in mind, my proposal looks pretty bad :-(
What do you think about solving the requirements of the *first* waiting
phase (Where we wait for current ShareLock holders) inside the lock manager?
The only real downside I can see is that I feel uneasy about messing with
that code... It seems to be subtle, and quick to anger ;-)
For the second phase, I see two options
.) Go forward with the transient XIDs / RIDs approach
.) Do something similar to the indcreatexid idea the HOT patch implements.
This essentially
puts the burden of deciding an index's usability on the using xact,
not on the one creating the index.
greetings, Florian Pflug
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
