| From: | Nick Cleaton <nick(at)cleaton(dot)net> |
|---|---|
| To: | Steve Baldwin <steve(dot)baldwin(at)gmail(dot)com> |
| Cc: | Perryn Fowler <perryn(at)fresho(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-14 12:31:53 |
| Message-ID: | CAFgz3kvn0uh+Cpv4sXtnM8Oiyp0ztit2zoY=13saX_8p-piSbQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
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 | Euler Taveira | 2022-04-14 14:15:20 | Re: Support logical replication of DDLs |
| Previous Message | Steve Baldwin | 2022-04-14 09:47:42 | Re: Is this a reasonable use for advisory locks? |