Jan Wieck [EMAIL PROTECTED] writes:
So far I was not able to reproduce the problem. If it is what we think,
then it should be possible to reproduce it with just one single DB
connection, no?
The reason it is difficult to reproduce is that when
StrategyInvalidateBuffer puts a dead buffer on
Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
Yeah, looks like ... but I actually want to have a clean reproduction of
the error before I attempt to fix it.
Well, I can tell you that just running make check over and over isn't
a real efficient way to reproduce the problem. It might work
Tom Lane wrote:
Note that buffer 160 gets cleared twice in this sequence. The second
time, the CDB for 174 gets found, leading to failure when 174 is cleared.
I believe the correct fix is to do CLEAR_BUFFERTAG on the buffer (and
maybe the CDB too?) when returning a buffer to the freelist in
Tom Lane [EMAIL PROTECTED] writes:
It might also be worthwhile to add another BM_FLAG bit that
specifically indicates a buffer is on the freelist, and
set/clear/test that at appropriate spots.
ISTM that BM_FREE should indicate this, or am I misunderstanding you?
-Neil
Neil Conway [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
It might also be worthwhile to add another BM_FLAG bit that
specifically indicates a buffer is on the freelist, and
set/clear/test that at appropriate spots.
ISTM that BM_FREE should indicate this, or am I
Tom Lane [EMAIL PROTECTED] writes:
It might be a good idea to rename BM_FREE to something else, perhaps
BM_UNPINNED, since I can recall being confused about what it meant
too.
If all it indicates is refcount == 0, ISTM we can just get rid of it
altogether, and just check the shared refcount
Neil Conway [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
It might be a good idea to rename BM_FREE to something else, perhaps
BM_UNPINNED, since I can recall being confused about what it meant
too.
If all it indicates is refcount == 0, ISTM we can just get rid of it
I just had the parallel regression tests hang up due to what appears to
be a bug in the new ARC code. The CLUSTER test gets into an infinite
loop trying to do CLUSTER clstr_1;. The loop is in
StrategyInvalidateBuffer's check that the buffer is already in the
freelist; it isn't, and the freelist
Tom Lane wrote:
I just had the parallel regression tests hang up due to what appears to
be a bug in the new ARC code. The CLUSTER test gets into an infinite
loop trying to do CLUSTER clstr_1;. The loop is in
StrategyInvalidateBuffer's check that the buffer is already in the
freelist; it isn't,
Jan Wieck [EMAIL PROTECTED] writes:
It seems to me that buffers that are thrown away via
StrategyInvalidateBuffer() do not get their relnode and blocknum cleaned
out.
Mmmm. They definitely should be; if you look at the prior version of
buf_table.c, BufTableDelete did this:
/*
*
BTW, I just managed to reproduce the hang, after a whole afternoon of
trying ... only it was with a non-debug build. Sigh. Anyway, it seems
my HP machine has a significantly higher probability of showing the
problem than my Linux machine --- I have been unable to see the problem
in thirty or
Tom Lane wrote:
BTW, I just managed to reproduce the hang, after a whole afternoon of
trying ... only it was with a non-debug build. Sigh. Anyway, it seems
my HP machine has a significantly higher probability of showing the
problem than my Linux machine --- I have been unable to see the problem
Jan Wieck [EMAIL PROTECTED] writes:
Let me know if there's any test I could run to confirm your theory,
assuming I can make it happen again after I finish rebuilding.
You could add another assertion that checks that the CDB found is
actually pointing to the buffer that is being invalidated.
Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
It seems to me that buffers that are thrown away via
StrategyInvalidateBuffer() do not get their relnode and blocknum cleaned
out.
Mmmm. They definitely should be; if you look at the prior version of
buf_table.c, BufTableDelete did this:
14 matches
Mail list logo
