Re: Is this a reasonable use for advisory locks?

From: Perryn Fowler <perryn(at)fresho(dot)com>
To: Nick Cleaton <nick(at)cleaton(dot)net>
Cc: Steve Baldwin <steve(dot)baldwin(at)gmail(dot)com>, "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: Is this a reasonable use for advisory locks?
Date: 2022-04-15 08:41:58
Message-ID: CAK6N2dgQAnHDNHAP+rYs8wF9FUhwV_vhGK9yvf117X88YykA=g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)cleaton(dot)net> wrote:

> On Thu, 14 Apr 2022 at 10:47, Steve Baldwin <steve(dot)baldwin(at)gmail(dot)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.
>

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Sonai muthu raja M 2022-04-15 09:11:59 Require details that can we see the password history to a User account in PostgreSQL Database.
Previous Message Zheng Li 2022-04-15 02:08:58 Re: Support logical replication of DDLs