| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | Sylvain Déve <sylvain(dot)deve(at)protonmail(dot)com> |
| Cc: | "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Update concurrency |
| Date: | 2021-12-20 13:52:03 |
| Message-ID: | CAKFQuwbDjaigik_HBiW90WtorFeeEQEw_e+jBdR2jiCCbQ42Zw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Monday, December 20, 2021, Sylvain Déve <sylvain(dot)deve(at)protonmail(dot)com>
wrote:
>
> To summarize, how can I allow for multiple updates of the same attributes,
> one after another, even when these updates are requested almost at the same
> time from independent, uncontrollable client requests?
>
Most people use an application connect pool. You replace “connect” with a
call to get a connection from the pool. When you are done you release the
connect back to the pool. Concurrency is then done by having a pool size
greater than one. If you try doing more concurrent work than the pool size
allows the pool call should block and/lr return a nothing upon which you
loop and try again.
David J.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Christoph Moench-Tegeder | 2021-12-20 14:22:31 | Re: md5 issues Postgres14 on OL7 |
| Previous Message | Sylvain Déve | 2021-12-20 13:45:29 | Update concurrency |