Justin Pryzby wrote:
> detail|Process 26871 waits for ShareLock on transaction 13693505; blocked by
> process 26646.
> Process 26646 waits for ShareLock on transaction 13693504; blocked by process
> 26871.
> Process 26871: SELECT db_column_name,table_name FROM
> huawei_m2000_counter_details ORD
On Sat, Jun 10, 2017 at 03:16:26PM -0400, Tom Lane wrote:
> Rob Nikander writes:
> >> On Jun 10, 2017, at 10:34 AM, Tom Lane wrote:
> >> […] but it'd be better to adjust the query to ensure a deterministic
> >> update order.
>
> > Thank you for the answer. Since `update` has no `order by` clause
Rob Nikander writes:
>> On Jun 10, 2017, at 10:34 AM, Tom Lane wrote:
>> […] but it'd be better to adjust the query to ensure a deterministic
>> update order.
> Thank you for the answer. Since `update` has no `order by` clause, I’m
> guessing there’s no way to do this with just the `update` sta
> On Jun 10, 2017, at 10:34 AM, Tom Lane wrote:
> […] but it'd be better to adjust the query to ensure a deterministic
> update order.
Thank you for the answer. Since `update` has no `order by` clause, I’m guessing
there’s no way to do this with just the `update` statement, and that I should
u
Rob Nikander writes:
> I’m trying to track down a deadlock happening in a live app. I’m wondering
> about statements like this, which select more than one row to update:
> update t set num = 1 where name = ‘foo’;
> It appears to be causing a deadlock, but I can’t reproduce it on my test
> d
Hi,
I’m trying to track down a deadlock happening in a live app. I’m wondering
about statements like this, which select more than one row to update:
update t set num = 1 where name = ‘foo’;
It appears to be causing a deadlock, but I can’t reproduce it on my test
database. Could two thread
