Re: Is this a reasonable use for advisory locks? - Mailing list pgsql-general

From Perryn Fowler
Subject Re: Is this a reasonable use for advisory locks?
Date
Msg-id CAK6N2dgQAnHDNHAP+rYs8wF9FUhwV_vhGK9yvf117X88YykA=g@mail.gmail.com
Whole thread Raw
In response to Re: Is this a reasonable use for advisory locks?  (Nick Cleaton <nick@cleaton.net>)
Responses Re: Is this a reasonable use for advisory locks?  (Michael Lewis <mlewis@entrata.com>)
List pgsql-general

Hey Nick, 

Thanks! Yep that’s an alternative (together with a uniqueness constraint and retry mechanism)

I guess what I’m trying to get my head around is whether and why this would be better than using advisory locks…

Cheers
Perryn 

On Thu, 14 Apr 2022 at 10:32 pm, Nick Cleaton <nick@cleaton.net> wrote:
On Thu, 14 Apr 2022 at 10:47, Steve Baldwin <steve.baldwin@gmail.com> wrote:
Ok, so you want to allow _other_ updates to a customer while this process is happening? In that case, advisory locks will probably work. The only consideration is that the 'id' is a bigint. If your customer id maps to that, great. If not (for example we use UUID's), you will need some way to convert that id to a bigint.

Alternatively, create a new table that records the start timestamp of the most recent run of your code block for each customer, and update that as the first action in your transaction. Then row locks on that table will protect you from concurrent runs.

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: ERROR: XX000: cache lookup failed for type 75083631
Next
From: "Sonai muthu raja M"
Date:
Subject: Require details that can we see the password history to a User account in PostgreSQL Database.