On 13 April 2014 16:44, Andres Freund and...@2ndquadrant.com wrote:
On 2014-04-12 17:40:34 -0400, Robert Haas wrote:
On Fri, Apr 11, 2014 at 10:28 AM, Andres Freund and...@2ndquadrant.com
wrote:
VACUUM sometimes waits synchronously for a cleanup lock on a heap
page. Sometimes for a long
On 2014-04-14 15:45:45 +0100, Simon Riggs wrote:
On 13 April 2014 16:44, Andres Freund and...@2ndquadrant.com wrote:
On 2014-04-12 17:40:34 -0400, Robert Haas wrote:
On Fri, Apr 11, 2014 at 10:28 AM, Andres Freund and...@2ndquadrant.com
wrote:
VACUUM sometimes waits synchronously for a
On Mon, Apr 14, 2014 at 10:50 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-04-14 15:45:45 +0100, Simon Riggs wrote:
On 13 April 2014 16:44, Andres Freund and...@2ndquadrant.com wrote:
On 2014-04-12 17:40:34 -0400, Robert Haas wrote:
On Fri, Apr 11, 2014 at 10:28 AM, Andres Freund
Andres Freund and...@2ndquadrant.com writes:
On 2014-04-14 15:45:45 +0100, Simon Riggs wrote:
On 13 April 2014 16:44, Andres Freund and...@2ndquadrant.com wrote:
What I am not sure about is how... It's trivial to set
pg_stat_activity.waiting = true, but without a corresponding description
On 2014-04-14 11:30:02 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-04-14 15:45:45 +0100, Simon Riggs wrote:
On 13 April 2014 16:44, Andres Freund and...@2ndquadrant.com wrote:
What I am not sure about is how... It's trivial to set
pg_stat_activity.waiting =
Andres Freund and...@2ndquadrant.com writes:
On 2014-04-14 11:30:02 -0400, Tom Lane wrote:
I wonder whether we should not try to fix this by making the process wait
on a heavyweight lock, if it has to wait. That would also get us out of
the rather grotty business of using a special-purpose
On Mon, Apr 14, 2014 at 12:02 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-04-14 11:30:02 -0400, Tom Lane wrote:
I wonder whether we should not try to fix this by making the process wait
on a heavyweight lock, if it has to wait. That would also
On 2014-04-14 12:02:22 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-04-14 11:30:02 -0400, Tom Lane wrote:
I wonder whether we should not try to fix this by making the process wait
on a heavyweight lock, if it has to wait. That would also get us out of
the
On 2014-04-14 12:21:09 -0400, Robert Haas wrote:
AFAICS, the big advantage of something like this is that we'd get
proper deadlock detection, and that's not a trivial point.
Hm. Is this actually something we need? I am not aware of deadlock prone
scenarios involving buffer pins during normal
Tom Lane wrote:
In an ideal world, when we needed to wait for a cleanup lock, we'd cause
the lock manager to set up pre-granted sharable page locks for all the
processes currently holding buffer pins, and then wait for an exclusive
page lock. The current hack of signaling when you're the
Andres Freund and...@2ndquadrant.com writes:
On 2014-04-14 12:21:09 -0400, Robert Haas wrote:
AFAICS, the big advantage of something like this is that we'd get
proper deadlock detection, and that's not a trivial point.
Hm. Is this actually something we need? I am not aware of deadlock prone
On 2014-04-14 13:06:21 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-04-14 12:21:09 -0400, Robert Haas wrote:
AFAICS, the big advantage of something like this is that we'd get
proper deadlock detection, and that's not a trivial point.
Hm. Is this actually
Andres Freund and...@2ndquadrant.com writes:
On 2014-04-14 13:06:21 -0400, Tom Lane wrote:
In particular I'm not sold on the use-case
for being able to tell that a process is waiting without being able to
tell what it's waiting for. I can figure that much out already.
You can? How? It could
On Mon, Apr 14, 2014 at 1:26 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-04-14 13:06:21 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-04-14 12:21:09 -0400, Robert Haas wrote:
AFAICS, the big advantage of something like this is that we'd get
proper
On 4/14/14, 12:06 PM, Tom Lane wrote:
One concrete reason not to do the proposed trivial hack is that the lock
readout views are asynchronous. Right now, if someone sees a process that
claims to be waiting but they don't see any entry in pg_locks, they know
they saw inconsistent state. If we
On 4/14/14, 12:44 PM, Tom Lane wrote:
Andres Freundand...@2ndquadrant.com writes:
On 2014-04-14 13:06:21 -0400, Tom Lane wrote:
In particular I'm not sold on the use-case
for being able to tell that a process is waiting without being able to
tell what it's waiting for. I can figure that much
On 2014-04-12 17:40:34 -0400, Robert Haas wrote:
On Fri, Apr 11, 2014 at 10:28 AM, Andres Freund and...@2ndquadrant.com
wrote:
VACUUM sometimes waits synchronously for a cleanup lock on a heap
page. Sometimes for a long time. Without reporting it externally.
Rather confusing ;).
Since
On Sun, Apr 13, 2014 at 9:14 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-04-12 17:40:34 -0400, Robert Haas wrote:
On Fri, Apr 11, 2014 at 10:28 AM, Andres Freund and...@2ndquadrant.com
wrote:
VACUUM sometimes waits synchronously for a cleanup lock on a heap
page. Sometimes for
On Fri, Apr 11, 2014 at 10:28 AM, Andres Freund and...@2ndquadrant.com wrote:
VACUUM sometimes waits synchronously for a cleanup lock on a heap
page. Sometimes for a long time. Without reporting it externally.
Rather confusing ;).
Since we only take cleanup locks around vacuum, how about we
19 matches
Mail list logo
