Alvaro Herrera <alvherre(at)commandprompt(dot)com> wrote:
> Excerpts from Heikki Linnakangas's message of mié jun 08 05:45:35
-0400 2011:
>> On 08.06.2011 12:36, Dan Ports wrote:
>
>>> The only thing I'd be worried about is that at some future point
>>> we might add heap page locks -- say, for sequential scans that
>>> don't read the entire relation -- and expect inserts to be
>>> tested against them. I'm not sure whether we'd actually do
>>> this, but we wanted to keep the option open during development.
>>
>> I think that is only relevant for queries like "SELECT * FROM
>> table WHERE ctid = '(12,34)'. You might expect that we take a
>> lock on that physical part of the heap, so that an INSERT that
>> falls on that slot would conflict, but one that falls elsewhere
>> does not. At the moment, a TidScan only takes a predicate lock
>> tuples that exist, it doesn't try to lock the range like an
>> IndexScan would.
>>
>> The physical layout of the table is an implementation detail that
>> the application shouldn't care about, so I don't feel sorry for
>> anyone doing that. Maybe it's worth mentioning somewhere in the
>> docs, though.
Agreed. I'll add it to my list.
> What about UPDATE WHERE CURRENT OF?
That doesn't currently lock anything except rows actually read, does
it? If not, that has no bearing on the suggested change. Also, any
row read through any *other* means during the same transaction would
already have a predicate lock which would cover the tuple, so any
case where you read the TID from a tuple and then use that to
re-visit the tuple during the same transaction would not be
affected. We're talking about whether it makes any sense to blindly
read a TID, and if it's not found, to remember the fact that that
particular TID *wasn't* there, and generate a rw-conflict if an
overlapping transaction does something which *creates* a tuple with
that TID. That does seem to be an unlikely use case. If we decide
not to support SSI conflict detection in that usage, we can save
some CPU time, reduce LW lock contention, and reduce the false
positive rate for serialization failures.
> Also, people sometimes use CTID to eliminate duplicate rows.
Again, I presume that if they want transactional behavior on that,
they would read the duplicates and do the delete within the same
transaction? If so there's no chance of a problem. If not, we're
talking about wanting to create a rw-conflict with an overlapping
transaction which reused the same TID, which I'm not sure is even
possible, or that it makes sense to care about the TID matching
anyway.
-Kevin