Tom Lane wrote:
> "Florian G. Pflug" <fgp@phlo.org> 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
tothe indcreatexid idea the HOT patch implements. This essentially puts the burden of deciding an index's
usabilityon the using xact, not on the one creating the index.
greetings, Florian Pflug
