Re: Logical locking beyond pg_advisory
| От | marcelo |
|---|---|
| Тема | Re: Logical locking beyond pg_advisory |
| Дата | |
| Msg-id | e3040ff1-0db0-c644-2ba2-0c7511fcb657@gmail.com обсуждение |
| Ответ на | Re: Logical locking beyond pg_advisory (Chris Travers <chris.travers@gmail.com>) |
| Список | pgsql-general |
On 17/09/2018 14:27 , Chris Travers wrote:
You are right. But you know...On Mon, Sep 17, 2018 at 6:04 PM marcelo <marcelo.nicolet@gmail.com> wrote:I´m using an ORM (Devart´s) to access the database, so, I cannot "select ... FOR UPDATE". The application paradigm is that a user have a list of records (after a query) and she could update or delete any of them as the business rules allows it. So, at least an advisory lock is a must.
I´m convinced by now: I would stay with advisory locks... expecting no app crash could occur...I would say to fix this in the ORM rather than reinvent what the database already gives you in the database.
--Best Wishes,Chris TraversEfficito: Hosted Accounting and ERP. Robust and Flexible. No vendor lock-in.
В списке pgsql-general по дате отправления: