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 robertmh...@gmail.com wrote:
On Tue, Jun 7, 2011 at 3:24 PM, Greg Stark gsst...@mit.edu wrote:
On Mon, Jun 30, 2014 at 7:55 PM, Greg Stark st...@mit.edu wrote:
On Wed, Nov 2, 2011 at 3:19 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jun 7, 2011 at 3:24 PM, Greg Stark gsst...@mit.edu wrote:
Well it's super-exclusive-vacuum-lock avoidance techniques. Why
shouldn't it make more
On Wed, Nov 9, 2011 at 3:46 PM, Simon Riggs si...@2ndquadrant.com 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.
On Tue, Nov 8, 2011 at 3:26 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Nov 8, 2011 at 2:26 AM, Simon Riggs si...@2ndquadrant.com wrote:
I think we need to avoid long pin hold times generally.
In the case of a suspended sequential scan, which is
On Wed, Nov 9, 2011 at 9:12 PM, Robert Haas robertmh...@gmail.com 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
On Wed, Nov 9, 2011 at 9:48 PM, simon si...@2ndquadrant.com wrote:
On Wed, Nov 9, 2011 at 9:12 PM, Robert Haas robertmh...@gmail.com 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
Robert Haas robertmh...@gmail.com 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
Simon Riggs si...@2ndquadrant.com 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
On Wed, Nov 9, 2011 at 10:20 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com 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
On Wed, Nov 9, 2011 at 5:18 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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.
On Wed, Nov 9, 2011 at 6:10 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, Nov 9, 2011 at 10:20 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
heapgetpage() gets a page and a pin, but holds the pin until it reads
the next page. Wow!
That is both
On Tue, Nov 8, 2011 at 2:26 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Tue, Nov 8, 2011 at 2:54 AM, Robert Haas robertmh...@gmail.com 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
On Tue, Nov 8, 2011 at 1:50 PM, Robert Haas robertmh...@gmail.com 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
On Tue, Nov 8, 2011 at 10:08 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Tue, Nov 8, 2011 at 1:50 PM, Robert Haas robertmh...@gmail.com 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
Robert Haas robertmh...@gmail.com writes:
On Tue, Nov 8, 2011 at 2:26 AM, Simon Riggs si...@2ndquadrant.com 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
On Tue, Nov 8, 2011 at 10:26 AM, Tom Lane t...@sss.pgh.pa.us 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
Robert Haas robertmh...@gmail.com 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
On Tue, Nov 8, 2011 at 10:54 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
On Fri, Nov 4, 2011 at 3:39 PM, Robert Haas robertmh...@gmail.com 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
On Tue, Nov 8, 2011 at 2:54 AM, Robert Haas robertmh...@gmail.com 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
On Thu, Nov 3, 2011 at 12:57 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Thu, Nov 3, 2011 at 2:22 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Nov 3, 2011 at 9:52 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Thu, Nov 3, 2011 at 1:26 PM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Nov 4, 2011 at 6:18 PM, Robert Haas robertmh...@gmail.com 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:
+
On Fri, Nov 4, 2011 at 3:12 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Fri, Nov 4, 2011 at 6:18 PM, Robert Haas robertmh...@gmail.com 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
On Sun, Jun 5, 2011 at 4:03 AM, Robert Haas robertmh...@gmail.com 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,
On Thu, Nov 3, 2011 at 7:15 AM, Simon Riggs si...@2ndquadrant.com 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,
On Thu, Nov 3, 2011 at 1:26 PM, Robert Haas robertmh...@gmail.com 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.
On Thu, Nov 3, 2011 at 9:52 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Thu, Nov 3, 2011 at 1:26 PM, Robert Haas robertmh...@gmail.com 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
On Thu, Nov 3, 2011 at 2:22 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Nov 3, 2011 at 9:52 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Thu, Nov 3, 2011 at 1:26 PM, Robert Haas robertmh...@gmail.com wrote:
I think that should be OK, but:
- It looks to me like you haven't done
On Tue, Jun 7, 2011 at 3:24 PM, Greg Stark gsst...@mit.edu 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
On Mon, Jun 6, 2011 at 11:30 PM, Simon Riggs si...@2ndquadrant.com 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
On Tue, Jun 7, 2011 at 8:24 PM, Greg Stark gsst...@mit.edu wrote:
On Mon, Jun 6, 2011 at 11:30 PM, Simon Riggs si...@2ndquadrant.com 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.
On Tue, Jun 7, 2011 at 3:43 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Tue, Jun 7, 2011 at 8:24 PM, Greg Stark gsst...@mit.edu wrote:
On Mon, Jun 6, 2011 at 11:30 PM, Simon Riggs si...@2ndquadrant.com wrote:
But I think you've hit the important point here. The problem is not
whether
On Mon, Jun 6, 2011 at 12:19 AM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
On Sun, Jun 5, 2011 at 12:03, Robert Haas robertmh...@gmail.com 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
On Jun 6, 2011, at 1:00 AM, Robert Haas wrote:
On Mon, Jun 6, 2011 at 12:19 AM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
On Sun, Jun 5, 2011 at 12:03, Robert Haas robertmh...@gmail.com wrote:
If other buffer pins do exist, then we can't
defragment the page, but that doesn't mean no
On Sun, Jun 5, 2011 at 8:33 AM, Robert Haas robertmh...@gmail.com 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,
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
On Sun, Jun 5, 2011 at 4:03 AM, Robert Haas robertmh...@gmail.com 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,
On Mon, Jun 6, 2011 at 2:36 AM, Pavan Deolasee pavan.deola...@gmail.com 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
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
On Mon, Jun 6, 2011 at 12:49 PM, Alvaro Herrera
alvhe...@commandprompt.com 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
On Mon, Jun 6, 2011 at 8:02 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
On Sun, Jun 5, 2011 at 12:03, Robert Haas robertmh...@gmail.com 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
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
43 matches
Mail list logo
