Fix locking error if IN/EXISTS is converted into a semi-join

[dyemanov]

Example:

select * from T1 where exists (select null from T2 where T2.PARENT_ID =T1.ID) with lock

raises an error "Stream does not support record locking" because EXISTS is converted into a semi-join but joins don't support record locking. It affects v6 and v5 with SubQueryConversion setting enabled.

It could be fixed by disabling sub-query conversion if WITH LOCK is used for a parent query, but I prefer to fix it at the join level - because it allows faster query plans. Also I'd suggest to consider whether we should generally allow record locking for joins in v6. PG allows that, but it also allows (optionally) to specify which joined table must be locked -- which we miss.

The provided patch is for v5. I'm postponing a patch for v6 for a little bit, expecting some feedback on the question above.

[aafemt]

Also I'd suggest to consider whether we should generally allow record locking for joins in v6. PG allows that, but it also allows (optionally) to specify which joined table must be locked -- which we miss.

Code in v6 is mostly prepared to work with composite DB_KEYs so I would expect no problem during implementation of for update, with lock and where current of for joins, even with locking corresponding record(s) in every involved table at first stage.

[dyemanov]

Also I'd suggest to consider whether we should generally allow record locking for joins in v6. PG allows that, but it also allows (optionally) to specify which joined table must be locked -- which we miss.

Code in v6 is mostly prepared to work with composite DB_KEYs so I would expect no problem during implementation of for update, with lock and where current of for joins, even with locking corresponding record(s) in every involved table at first stage.

update/delete ... where current of affects only one table, while with lock affects all the joined tables at once. So far I cannot imagine when it could be useful (except intention to lock one table and locking others is considered being an acceptable side effect).

[aafemt]

Yes, it is an unfortunate side-effect, but you can consider following pseudo-code of synchronization of two tables:

for select ... from a full outer join b ... do
if ... then delete from a where current of ...
else delete from b where current of ...

[EPluribusUnum]

Conversion must have no side effects! Lock shold be applied only for one table, as the original statements defined it. If single table lock not possbible, then reject conversion and run the original statement.

[dyemanov]

Conversion must have no side effects! Lock shold be applied only for one table, as the original statements defined it. If single table lock not possbible, then reject conversion and run the original statement.

The question was not about conversion (it will lock just one table), but about WITH LOCK applied to regular joins.

[aafemt]

How about extending WITH LOCK syntax to WITH LOCK [OF <table list>] and default to all joined tables (except converted semi-join, as you said, of course)?

[dyemanov]

How about extending WITH LOCK syntax to WITH LOCK [OF <table list>] and default to all joined tables (except converted semi-join, as you said, of course)?

This is how PG does it. I'm OK with that, although a new BLR verb will be needed. As for the syntax, should it be WITH LOCK [OF <table list>] [SKIP LOCKED] or WITH LOCK [(<table list>)] [SKIP LOCKED] or maybe something else?

[dyemanov]

So far I'm not sure how to process A JOIN B ... WITH LOCK if lock(A) returns LOCKED and lock(b) returns SKIPPED. I will defer the generic solution until I'm able to figure it out ;)

[hvlad]

How about extending WITH LOCK syntax to WITH LOCK [OF <table list>] and default to all joined tables (except converted semi-join, as you said, of course)?

This is how PG does it.

Looks like a (very questionable) workaround.
Pessimistic lock for more than one record looks suspicious already, but locks for many tables is definitely bad.

[hvlad]

So far I'm not sure how to process A JOIN B ... WITH LOCK if lock(A) returns LOCKED and lock(b) returns SKIPPED. I will defer the generic solution until I'm able to figure it out ;)

Again, it is bad idea to allow pessimistic lock for joins.

[dyemanov]

How about extending WITH LOCK syntax to WITH LOCK [OF <table list>] and default to all joined tables (except converted semi-join, as you said, of course)?

This is how PG does it.

Looks like a (very questionable) workaround. Pessimistic lock for more than one record looks suspicious already, but locks for many tables is definitely bad.

I agree this is questionable. However, it's up to user to decide why they specify WITH LOCK for a JOIN. If this is intentional, I'd expect the user to also specify which particular joined stream must be locked. If this hasn't been done, well - we either raise an error (as now) or allow locking of all tables just as a side effect (because we don't know what exactly was intended to be locked, but locking was explicitly requested).

All that said, I'm not going to implement it right now.

[hvlad]

I agree this is questionable.

The more I think on it, the less I like it, see:

• how order of locking with more then one stream could be known for end user ?
• how end user can know it in advance to avoid hard to find deadlocks ?
• can it be guaranteed that the order of locking will not be changed ?

All that said, I'm not going to implement it right now.

Good, but your patch allowed locking for at least some kind joins, isn't is ?
How it will work with, say

SELECT ... FROM T1 JOIN T2 ... WHERE EXISTS (SELECT ... FROM T3) ... WITH LOCK?

what table will be locked T1 or T2 ?