On Mon, Jun 30, 2014 at 7:55 PM, Greg Stark wrote:
> On Wed, Nov 2, 2011 at 3:19 PM, Robert Haas wrote:
>> On Tue, Jun 7, 2011 at 3:24 PM, Greg Stark wrote:
>>> Well it's super-exclusive-vacuum-lock avoidance techniques. Why
>>> shouldn't it make more sense to try to reduce the frequency and imp
Zombie thread arise!
I was searching for old threads on a specific problem and came across
this patch that was dropped due to concerns about SnapshotNow:
On Wed, Nov 2, 2011 at 3:19 PM, Robert Haas wrote:
> On Tue, Jun 7, 2011 at 3:24 PM, Greg Stark wrote:
>> Well it's super-exclusive-vacuum-lo
On Wed, Nov 9, 2011 at 6:10 PM, Simon Riggs wrote:
> On Wed, Nov 9, 2011 at 10:20 PM, Tom Lane wrote:
>> Simon Riggs writes:
>>> heapgetpage() gets a page and a pin, but holds the pin until it reads
>>> the next page. Wow!
>>
>>> That is both annoying and very dumb. It should hold the pin long
>
On Wed, Nov 9, 2011 at 5:18 PM, Tom Lane wrote:
> Robert Haas writes:
>> As for what to do about all this, I think Tom's idea would work for
>> good tuples, but the current freezing code can't handle dead tuples;
>> it counts on those having been already removed.
>
> I have not gone back to look
On Wed, Nov 9, 2011 at 10:20 PM, Tom Lane wrote:
> Simon Riggs writes:
>> heapgetpage() gets a page and a pin, but holds the pin until it reads
>> the next page. Wow!
>
>> That is both annoying and very dumb. It should hold the pin long
>> enough to copy the data and then release the pin.
>
> I d
Simon Riggs writes:
> heapgetpage() gets a page and a pin, but holds the pin until it reads
> the next page. Wow!
> That is both annoying and very dumb. It should hold the pin long
> enough to copy the data and then release the pin.
I don't find that anywhere near as obvious as you seem to. I t
Robert Haas writes:
> As for what to do about all this, I think Tom's idea would work for
> good tuples, but the current freezing code can't handle dead tuples;
> it counts on those having been already removed.
I have not gone back to look at the code, but are you worried about the
fact that it d
On Wed, Nov 9, 2011 at 9:48 PM, simon wrote:
> On Wed, Nov 9, 2011 at 9:12 PM, Robert Haas wrote:
>
>> Well, I'm not sure of the details of how page-at-a-time mode works for
>> seq scans, but I am absolutely 100% sure that you can reproduce this
>> problem using a cursor over a sequential scan.
On Wed, Nov 9, 2011 at 9:12 PM, Robert Haas wrote:
> Well, I'm not sure of the details of how page-at-a-time mode works for
> seq scans, but I am absolutely 100% sure that you can reproduce this
> problem using a cursor over a sequential scan. Just do this:
>
> create table test (a text);
> inse
On Tue, Nov 8, 2011 at 3:26 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Nov 8, 2011 at 2:26 AM, Simon Riggs wrote:
>>> I think we need to avoid long pin hold times generally.
>
>> In the case of a suspended sequential scan, which is the case where
>> this has most recently bitten me on
On Wed, Nov 9, 2011 at 3:46 PM, Simon Riggs wrote:
> Holding buffer pins for a long time is a problem in Hot Standby also,
> not just vacuum.
Agreed.
> AFAIK seq scans already work page at a time for normal tables. So the
> issue is when we *aren't* using a seq scan, e.g. nested loops joins.
>
>
On Tue, Nov 8, 2011 at 10:54 AM, Tom Lane wrote:
> Robert Haas writes:
>> Interesting idea. I think in general we insist that you must have a
>> buffer content lock to inspect the tuple visibility info, in which
>> case that would be safe. But I'm not sure we do that absolutely
>> everywhere.
Robert Haas writes:
> Interesting idea. I think in general we insist that you must have a
> buffer content lock to inspect the tuple visibility info, in which
> case that would be safe. But I'm not sure we do that absolutely
> everywhere. For instance, just last night I noticed this:
>
On Tue, Nov 8, 2011 at 10:26 AM, Tom Lane wrote:
> It strikes me that the only case where vacuum now has to wait is where
> it needs to freeze an old XID. Couldn't it do that without insisting on
> exclusive access? We only need exclusive access if we're going to move
> data around, but we could
Robert Haas writes:
> On Tue, Nov 8, 2011 at 2:26 AM, Simon Riggs wrote:
>> I think we need to avoid long pin hold times generally.
> In the case of a suspended sequential scan, which is the case where
> this has most recently bitten me on a production system, it actually
> seems rather unnecess
On Tue, Nov 8, 2011 at 10:08 AM, Simon Riggs wrote:
> On Tue, Nov 8, 2011 at 1:50 PM, Robert Haas wrote:
>> But there's an efficiency argument against doing it that way. First,
>> if we release the pin then we'll have to reacquire the buffer, which
>> means taking and releasing a BufMappingLock,
On Tue, Nov 8, 2011 at 1:50 PM, Robert Haas wrote:
> But there's an efficiency argument against doing it that way. First,
> if we release the pin then we'll have to reacquire the buffer, which
> means taking and releasing a BufMappingLock, the buffer header
> spinlock, and the buffer content loc
On Tue, Nov 8, 2011 at 2:26 AM, Simon Riggs wrote:
> On Tue, Nov 8, 2011 at 2:54 AM, Robert Haas wrote:
>> It would still be nice to fix the case where we need to freeze a tuple
>> that is on a page someone else has pinned, but I don't have any good
>> ideas for how to do that.
>
> I think we nee
On Tue, Nov 8, 2011 at 2:54 AM, Robert Haas wrote:
> It would still be nice to fix the case where we need to freeze a tuple
> that is on a page someone else has pinned, but I don't have any good
> ideas for how to do that.
I think we need to avoid long pin hold times generally.
--
Simon Riggs
On Fri, Nov 4, 2011 at 3:39 PM, Robert Haas wrote:
> Doing that actually makes the patch simpler, so I went ahead and did
> that in the attached version, along with the renaming mentioned above.
Hearing no objections, I went ahead and committed this version.
Thanks for coding this up; I think th
On Fri, Nov 4, 2011 at 3:12 PM, Simon Riggs wrote:
> On Fri, Nov 4, 2011 at 6:18 PM, Robert Haas wrote:
>
>> Here's a new version. I fixed the second pass as discussed (which
>> turned out to be trivial). To address the concern about relpages, I
>> moved this pre-existing line to after we get t
On Fri, Nov 4, 2011 at 6:18 PM, Robert Haas wrote:
> Here's a new version. I fixed the second pass as discussed (which
> turned out to be trivial). To address the concern about relpages, I
> moved this pre-existing line to after we get the buffer lock:
>
> + vacrelstats->scanned_p
On Thu, Nov 3, 2011 at 12:57 PM, Simon Riggs wrote:
> On Thu, Nov 3, 2011 at 2:22 PM, Robert Haas wrote:
>> On Thu, Nov 3, 2011 at 9:52 AM, Simon Riggs wrote:
>>> On Thu, Nov 3, 2011 at 1:26 PM, Robert Haas wrote:
>>>
I think that should be OK, but:
- It looks to me like you have
On Thu, Nov 3, 2011 at 2:22 PM, Robert Haas wrote:
> On Thu, Nov 3, 2011 at 9:52 AM, Simon Riggs wrote:
>> On Thu, Nov 3, 2011 at 1:26 PM, Robert Haas wrote:
>>
>>> I think that should be OK, but:
>>>
>>> - It looks to me like you haven't done anything about the second heap
>>> pass. That shoul
On Thu, Nov 3, 2011 at 9:52 AM, Simon Riggs wrote:
> On Thu, Nov 3, 2011 at 1:26 PM, Robert Haas wrote:
>
>> I think that should be OK, but:
>>
>> - It looks to me like you haven't done anything about the second heap
>> pass. That should probably get a similar fix.
>
> I was assuming this worked
On Thu, Nov 3, 2011 at 1:26 PM, Robert Haas wrote:
> I think that should be OK, but:
>
> - It looks to me like you haven't done anything about the second heap
> pass. That should probably get a similar fix.
I was assuming this worked with Pavan's patch to remove second pass.
Not in any rush to
On Thu, Nov 3, 2011 at 7:15 AM, Simon Riggs wrote:
>> A while
>> back, someone (Greg Stark? me?) floated the idea of not waiting for
>> the cleanup lock. If we can't get it immediately, or within some
>> short period of time, then we just skip the page and continue on.
>
> Separately, that sounds
On Sun, Jun 5, 2011 at 4:03 AM, Robert Haas wrote:
> We've occasionally seen problems with VACUUM getting stuck for failure
> to acquire a cleanup lock due to, for example, a cursor holding a pin
> on the buffer page. In the worst case, this can cause an undetected
> deadlock, if the backend hol
On Tue, Jun 7, 2011 at 3:24 PM, Greg Stark wrote:
> Well it's super-exclusive-vacuum-lock avoidance techniques. Why
> shouldn't it make more sense to try to reduce the frequency and impact
> of the single-purpose outlier in a non-critical-path instead of
> burdening every other data reader with ex
On Tue, Jun 7, 2011 at 3:43 PM, Simon Riggs wrote:
> On Tue, Jun 7, 2011 at 8:24 PM, Greg Stark wrote:
>> On Mon, Jun 6, 2011 at 11:30 PM, Simon Riggs wrote:
>>> But I think you've hit the important point here. The problem is not
>>> whether VACUUM waits for the pin, its that the pins can be hel
On Tue, Jun 7, 2011 at 8:24 PM, Greg Stark wrote:
> On Mon, Jun 6, 2011 at 11:30 PM, Simon Riggs wrote:
>> But I think you've hit the important point here. The problem is not
>> whether VACUUM waits for the pin, its that the pins can be held for
>> extended periods.
>
> Yes
>
>> It makes more sen
On Mon, Jun 6, 2011 at 11:30 PM, Simon Riggs wrote:
> But I think you've hit the important point here. The problem is not
> whether VACUUM waits for the pin, its that the pins can be held for
> extended periods.
Yes
> It makes more sense to try to limit pin hold times than it does to
> come up w
On Mon, Jun 6, 2011 at 8:02 AM, Heikki Linnakangas
wrote:
> On 06.06.2011 09:35, Jim Nasby wrote:
>>
>> I've had a related idea that I haven't looked into... if you're scanning a
>> relation (ie: index scan, seq scan) I've wondered if it would be more
>> efficient to deal with the entire page at o
On Mon, Jun 6, 2011 at 12:49 PM, Alvaro Herrera
wrote:
> Excerpts from Robert Haas's message of lun jun 06 08:06:10 -0400 2011:
>
>> But the problem of vacuum stalling out because it can't get the
>> cleanup lock is a very real one. I've seen at least one customer hit
>> this in production, and i
Excerpts from Robert Haas's message of lun jun 06 08:06:10 -0400 2011:
> But the problem of vacuum stalling out because it can't get the
> cleanup lock is a very real one. I've seen at least one customer hit
> this in production, and it was pretty painful. Now, granted, you need
> some bad appli
On Mon, Jun 6, 2011 at 2:36 AM, Pavan Deolasee wrote:
> Do we know if this is really a problem though ? The deadlock for
> example, can happen only when a backend tries to get a table level
> conflicting lock while holding the buffer pin and I am not sure if we
> do that.
The deadlock isn't terri
On Sun, Jun 5, 2011 at 4:03 AM, Robert Haas wrote:
> We've occasionally seen problems with VACUUM getting stuck for failure
> to acquire a cleanup lock due to, for example, a cursor holding a pin
> on the buffer page. In the worst case, this can cause an undetected
> deadlock, if the backend hold
On 06.06.2011 09:35, Jim Nasby wrote:
I've had a related idea that I haven't looked into... if you're scanning a
relation (ie: index scan, seq scan) I've wondered if it would be more efficient
to deal with the entire page at once, possibly be making a copy of it. This
would reduce the number o
On Sun, Jun 5, 2011 at 8:33 AM, Robert Haas wrote:
> We've occasionally seen problems with VACUUM getting stuck for failure
> to acquire a cleanup lock due to, for example, a cursor holding a pin
> on the buffer page. In the worst case, this can cause an undetected
> deadlock, if the backend hold
On Jun 6, 2011, at 1:00 AM, Robert Haas wrote:
> On Mon, Jun 6, 2011 at 12:19 AM, Itagaki Takahiro
> wrote:
>> On Sun, Jun 5, 2011 at 12:03, Robert Haas wrote:
>>> If other buffer pins do exist, then we can't
>>> defragment the page, but that doesn't mean no useful work can be done:
>>> we can st
On Mon, Jun 6, 2011 at 12:19 AM, Itagaki Takahiro
wrote:
> On Sun, Jun 5, 2011 at 12:03, Robert Haas wrote:
>> If other buffer pins do exist, then we can't
>> defragment the page, but that doesn't mean no useful work can be done:
>> we can still mark used line pointers dead, or dead line pointers
On Sun, Jun 5, 2011 at 12:03, Robert Haas wrote:
> If other buffer pins do exist, then we can't
> defragment the page, but that doesn't mean no useful work can be done:
> we can still mark used line pointers dead, or dead line pointers
> unused. We cannot defragment, but that can be done either b
We've occasionally seen problems with VACUUM getting stuck for failure
to acquire a cleanup lock due to, for example, a cursor holding a pin
on the buffer page. In the worst case, this can cause an undetected
deadlock, if the backend holding the buffer pin blocks trying to
acquire a heavyweight lo
43 matches
Mail list logo
