Long living and expiring locks?

From: Tim Uckun <timuckun(at)gmail(dot)com>
To: pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Long living and expiring locks?
Date: 2022-05-20 03:43:01
Message-ID: CAGuHJrOLL576+EBmUeXLNiHYtS5NRhdEZOqwUaVSipZhHufPOQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

I have multiple processes connecting to the same database. In order to
prevent race conditions the I would like the process to issue a
SELECT FOR UPDATE to lock the records that need to be processed.

The problem is that the locks are not inside of a single translation.
The process is multi step. Records are selected and presented to the
user, the user does some stuff and submits a form, the submitted form
updates those records and frees the lock.

Ideally I would do a select for update when the form is shown to the
user but with an expiry time so that if the user decides to move on
and not submit any changes the locks will expire.

I could do this with a locked_at field that I can update on select but
I would prefer to let postgres handle the locks if possible.

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Dominique Devienne 2022-05-20 06:50:57 Re: No default for (user-specific) service file location on Windows?
Previous Message Julien Rouhaud 2022-05-20 03:31:34 Re: No default for (user-specific) service file location on Windows?