From: | Jean Baro <jfbaro(at)gmail(dot)com> |
---|---|
To: | Michael Lewis <mlewis(at)entrata(dot)com> |
Cc: | MichaelDBA <MichaelDBA(at)sqlexec(dot)com>, Rick Otten <rottenwindfish(at)gmail(dot)com>, pgsql-performance(at)lists(dot)postgresql(dot)org |
Subject: | Re: High concurrency same row (inventory) |
Date: | 2019-07-30 00:06:57 |
Message-ID: | CA+fQeemmZgztnq89G+y5qUuLz810BEfgE=opJemdAhm-voNe_w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
The UPDATE was something like:
UPDATE bucket SET qty_available = qty_available + 1 WHERE bucket_uid =
0940850938059380590
Thanks for all your help guys!
On Mon, Jul 29, 2019 at 9:04 PM Jean Baro <jfbaro(at)gmail(dot)com> wrote:
> All the failures come from the Bucket Table (see image below).
>
> I don't have access to the DB, neither the code, but last time I was
> presented to the UPDATE it was changing (incrementing or decrementing)
> *qty_available*, but tomorrow morning I can be sure, once the developers
> and DBAs are back to the office. I know it's quite a simple UPDATE.
>
> Table is called Bucket:
> {autovacuum_vacuum_scale_factor=0.01}
>
> [image: Bucket.png]
>
>
> On Mon, Jul 29, 2019 at 3:12 PM Michael Lewis <mlewis(at)entrata(dot)com> wrote:
>
>> Can you share the schema of the table(s) involved and an example or two
>> of the updates being executed?
>>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Jean Baro | 2019-07-30 00:26:11 | Re: High concurrency same row (inventory) |
Previous Message | Jean Baro | 2019-07-30 00:04:55 | Re: High concurrency same row (inventory) |