I think a possible design would be to add an argument to
as a list of tables to lock. Now when the backend is called to lock a table,
it checks if it is a table already locked by the start of the transaction. If
it is not than it raises an exception that is catched by the starter of the
transaction which is responsible for adding the table to the list to lock
when re-starting the transaction.
Those difficulty could be avoided by using SERIALIZABLE isolation. This mode
is not available for now (we replaced by REPEATABLE READ) but maybe we could
allow to declare the need for such transaction (maybe depending on the tables
to lock) and in this case the LOCK calls and SELECT FOR could be ignored.
|2021-10-18 09:00:51||yangoon||set||messageid: <1634540451.0154305.QLRXJEGIJG6XKME6.firstname.lastname@example.org>|
|2021-10-18 09:00:51||yangoon||set||recipients: + ced|
|2021-10-18 09:00:50||yangoon||link||issue10870 messages|
Showing 10 items. Show all history (warning: this could be VERY long)