Re: can a blocked transaction affect the performance of one that is blocking it?

From: David Mullineux <dmullx(at)gmail(dot)com>
To: Eric Schwarzenbach <subscriber(at)blackbrook(dot)org>
Cc: pgsql-performance(at)lists(dot)postgresql(dot)org
Subject: Re: can a blocked transaction affect the performance of one that is blocking it?
Date: 2024-12-10 09:22:37
Message-ID: CAGsyd8X1b+EXzf8o2iYEnqHm6D-wZxzrUq_R_bHa9t8wFxMqyA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Yes.
Also, are you sure you mean deadlock ? It sounded like this is just a
simple lock conflict and not a deadlock.
The first transaction could be blocked on something else (even tho it's not
ally short and quick ).
Lock requests are in a queue

On Mon, 9 Dec 2024, 21:16 Eric Schwarzenbach, <subscriber(at)blackbrook(dot)org>
wrote:

> Hi,
>
> Could one transaction (one that should be relatively simple and short)
> cause another complex, long running transaction (involving INSERTS, on a
> table the first transaction may be reading from) to take many orders of
> magnitude longer than it would normally? (short of competing for system
> resources, like CPU time etc, of course)
>
> I don't believe my scenario involved a deadlock but I expect my short
> transaction was probably blocked by my long one. Does it make any sense
> that this could very significantly affect the performance of the
> non-blocked transaction?
>
> Thanks,
>
> Eric
>
>
>
>
>

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Greg Sabino Mullane 2024-12-10 13:03:28 Re: PostgreSQL and a Catch-22 Issue related to dead rows
Previous Message Lars Aksel Opsahl 2024-12-10 08:55:00 Re: PostgreSQL and a Catch-22 Issue related to dead rows