From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Melvin Davidson <melvin6925(at)gmail(dot)com> |
Cc: | Thomas Kellerer <spam_eater(at)gmx(dot)net>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Non-overlapping updates blocking each other |
Date: | 2017-10-14 16:32:33 |
Message-ID: | 13898.1507998753@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Melvin Davidson <melvin6925(at)gmail(dot)com> writes:
> On Sat, Oct 14, 2017 at 12:01 PM, Thomas Kellerer <spam_eater(at)gmx(dot)net>
> wrote:
>> Since when does Postgres lock the whole table during an update?
> When the optimizer thinks it needs to do a TABLE SCAN!
Sorry, but that's nonsense.
More likely explanations for the OP's problem involve foreign key
constraints that cause two different row updates to need to lock
the same referenced row, or maybe he's using some index type that
has greater locking demands than a btree, or he's using serializable
mode and fell foul of one of its approximations as to which rows
the update depends on, or perhaps some other corner case. We'd need
more info about the schema and the Postgres version to tell for sure.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | legrand legrand | 2017-10-15 10:07:53 | Re: SAP Application deployment on PostgreSQL |
Previous Message | Melvin Davidson | 2017-10-14 16:07:38 | Re: Non-overlapping updates blocking each other |