> Heikki Linnakangas wrote:
> On 30.04.2011 01:04, Kevin Grittner wrote:
>> TRUNCATE TABLE and DROP TABLE should generate a rw-conflict *in*
>> to the enclosing transaction (if it is serializable) from all
>> transactions holding predicate locks on the table or its indexes.
>> Note that this could cause a transactions which is running one of
>> these statements to roll back with a serialization error. This
>> seems correct to me, since these operations essentially delete all
>> rows. If you don't want the potential rollback, these operations
>> should be run at another isolation level. The difference between
>> these two statements is that I think that TRUNCATE TABLE should
>> also move the existing predicate locks to relation locks on the
>> table while DROP TABLE (for obvious reasons) should just delete
>> the predicate locks.
>
> Note that TRUNCATE has never been MVCC-safe anyway.
Yeah, Dan pointed out that another REPEATABLE READ or SERIALIZABLE
transaction *will* see the work of a committed TRUNCATE TABLE
statement, so it is not semantically identical to DELETE FROM with no
WHERE clause, which was something I somehow had gotten into my head.
> Perhaps it's best to just treat it like DROP TABLE.
We had been leaning that way based on the above observation.
> Or can we use the predicate lock mechanism to abort serializable
> transactions that incorrectly see the table as empty?
Predicate locks only interact with writes; it'd be a rather nasty
wart to try to bend them to the above use. I think we just have to
stick with the dictum which has controlled so far -- Serializable
Snapshot Isolation can only serialize those things which follow the
semantics of Snapshot Isolation. TRUNCATE TABLE doesn't.
>> DROP DATABASE should quietly clean up any predicate locks from
>> committed transactions which haven't yet hit their cleanup point
>> because of overlapping transactions in other databases.
>
> This is just an optimization, right? The predicate locks will
> eventually go away anyway.
Yes, correct. The only way they could create a problem besides just
taking up predicate lock slots is if a new database was created with
an identical OID before overlapping serializable transactions in
other databases completed; that seems rather far-fetched. Perhaps
DROP DATABASE is so infrequent that it's not worth the extra code to
do the early cleanup? The code to do that part might not carry its
own weight on a cost/benefit basis.
-Kevin
