Thank you for feedback.
On 26.08.2013 22:20, Alvaro Herrera wrote:
1. this assumes there is only one holder, which is not correct.
(Consider two backends holding shared lock on something and another one
stuck trying to acquire exclusive)
Hmm, true. Then it's not that simple as I thought in
Tarvi Pillessaar escribió:
Thank you for feedback.
On 26.08.2013 22:20, Alvaro Herrera wrote:
1. this assumes there is only one holder, which is not correct.
(Consider two backends holding shared lock on something and another one
stuck trying to acquire exclusive)
Hmm, true. Then it's
Fixed patch attached.
Regards,
Tarvi Pillessaar
On 24.08.2013 17:58, Peter Eisentraut wrote:
On Tue, 2013-08-20 at 19:21 +0300, Tarvi Pillessaar wrote:
About patch:
Patch is tested against 9.2.4.
I was not sure that i should check if the lock holder's proclock was
found (as lock holder's
Tarvi Pillessaar escribió:
Fixed patch attached.
1. this assumes there is only one holder, which is not correct.
(Consider two backends holding shared lock on something and another one
stuck trying to acquire exclusive)
2. I think pgstat_get_backend_current_activity() can be helpful.
3.
On Tue, 2013-08-20 at 19:21 +0300, Tarvi Pillessaar wrote:
About patch:
Patch is tested against 9.2.4.
I was not sure that i should check if the lock holder's proclock was
found (as lock holder's proclock should be always there), check is there
to be on the safe side, but maybe it's
Hello!
From time to time when investigating different locking issues using
postgres log i have thought that process x is still waiting for
message could be more informative, for example at the moment it is quite
painful to find out which session was actually holding that particular lock.
I
Tarvi Pillessaar tar...@gmail.com wrote:
Maybe someone can take a look at my patch and give some feedback.
Even if this idea won't reach to upstream, i would still like to get
feedback.
Please add the patch to the open CommitFest.
You can read about the process here:
