On 4/14/14, 12:44 PM, Tom Lane wrote:
Andres Freund 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.
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 ad
On Mon, Apr 14, 2014 at 1:26 PM, Andres Freund wrote:
> On 2014-04-14 13:06:21 -0400, Tom Lane wrote:
>> Andres Freund 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
Andres Freund 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 also be io or
On 2014-04-14 13:06:21 -0400, Tom Lane wrote:
> Andres Freund 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
Andres Freund 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
> scenarios involv
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
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 p
On 2014-04-14 12:02:22 -0400, Tom Lane wrote:
> Andres Freund 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 grott
On Mon, Apr 14, 2014 at 12:02 PM, Tom Lane wrote:
> Andres Freund 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 grot
Andres Freund 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 signal to wake it
On 2014-04-14 11:30:02 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-04-14 15:45:45 +0100, Simon Riggs wrote:
> >> On 13 April 2014 16:44, Andres Freund wrote:
> >>> What I am not sure about is how... It's trivial to set
> >>> pg_stat_activity.waiting = true, but without a correspond
Andres Freund writes:
> On 2014-04-14 15:45:45 +0100, Simon Riggs wrote:
>> On 13 April 2014 16:44, Andres Freund wrote:
>>> What I am not sure about is how... It's trivial to set
>>> pg_stat_activity.waiting = true, but without a corresponding description
>>> what the backend is waiting for it's
On Mon, Apr 14, 2014 at 10:50 AM, Andres Freund wrote:
> On 2014-04-14 15:45:45 +0100, Simon Riggs wrote:
>> On 13 April 2014 16:44, Andres Freund wrote:
>> > On 2014-04-12 17:40:34 -0400, Robert Haas wrote:
>> >> On Fri, Apr 11, 2014 at 10:28 AM, Andres Freund
>> >> wrote:
>> >> > VACUUM somet
On 2014-04-14 15:45:45 +0100, Simon Riggs wrote:
> On 13 April 2014 16:44, Andres Freund wrote:
> > On 2014-04-12 17:40:34 -0400, Robert Haas wrote:
> >> On Fri, Apr 11, 2014 at 10:28 AM, Andres Freund
> >> wrote:
> >> > VACUUM sometimes waits synchronously for a cleanup lock on a heap
> >> > pa
On 13 April 2014 16:44, Andres Freund wrote:
> On 2014-04-12 17:40:34 -0400, Robert Haas wrote:
>> On Fri, Apr 11, 2014 at 10:28 AM, Andres Freund
>> wrote:
>> > VACUUM sometimes waits synchronously for a cleanup lock on a heap
>> > page. Sometimes for a long time. Without reporting it externall
On Sun, Apr 13, 2014 at 9:14 PM, Andres Freund wrote:
> On 2014-04-12 17:40:34 -0400, Robert Haas wrote:
>> On Fri, Apr 11, 2014 at 10:28 AM, Andres Freund
>> wrote:
>> > VACUUM sometimes waits synchronously for a cleanup lock on a heap
>> > page. Sometimes for a long time. Without reporting it
On 2014-04-12 17:40:34 -0400, Robert Haas wrote:
> On Fri, Apr 11, 2014 at 10:28 AM, Andres Freund
> 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 ta
On Fri, Apr 11, 2014 at 10:28 AM, Andres Freund 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 report at
> least i
19 matches
Mail list logo
