Message 78571

Message id


On 2022-10-04 15:26, Albert Cervera i Areny wrote:
> - It gives little granularity on locking. We already have problems when there're table-level locks (using version 6.0 locks the whole sale_sale table and that produces too much contention).

Of course the proposed design does not change the lock granularity.

> - It still does not prevent the issue because when the lock occurs the transaction has already been started

It is by design impossible to lock outside a transaction.

> and so we can still have a scenario like the one described in issue11763: when the transaction starts the concurrent transaction is still running but when we try to acquire the lock the concurrent transaction has finished. This means that the second transaction can continue but the data it is seeing is already old.

No this is wrong. As explained by PostgreSQL documentation, it is not
the case as long as the lock is done before any SELECT or data
Date User Action Args
2022-10-04 15:43:16cedsetrecipients: + yangoon, albertca, acaubet
2022-10-04 15:43:16cedlinkissue10870 messages
2022-10-04 15:43:15cedcreate

Showing 10 items. Show all history (warning: this could be VERY long)