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.
>
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 |