Hi Tom,
Attached is a completed patch, which I've had no time to test yet, but
I have to leave for the evening right now --- so here it is in case
anyone is awake and wants to poke at it.
The patch was applied correctly only when I reverted Alvaro's first
patch, so I suppose it was meant to
Hi,
Should I try Alvaro's second patch that you said not going to work?
I'll add that this works for me, that's it prevents invalid alloc
requests to show.
Best regards
--
Matteo Beccati
http://phpadsnew.com
http://phppgads.com
---(end of
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Ok. I had hoped to reproduce the problem with pristine sources, in
order to verify that I was able to show it not appearing with my patch.
However I have been unable to create a situation in which the problem
appears. So I attach
Matteo Beccati wrote:
Hi,
Should I try Alvaro's second patch that you said not going to work?
I'll add that this works for me, that's it prevents invalid alloc
requests to show.
Yeah, the problem with that patch is that there's another, different
race condition, of much lower
Alvaro Herrera [EMAIL PROTECTED] writes:
I think I understand your approach, but I wonder why Matteo didn't find
an improvement with your patch. Maybe there's a bug on it?
Yeah, looking at it this morning, I got the retry condition wrong.
It might be fixable but I'm less enthused about it than
I wrote:
Your idea of handling the wraparound ambiguity by ignoring
InvalidTransactionId isn't bad --- I'll take a look at that.
OK, I think this version may actually work, and get the wraparound
case right too. It hasn't failed yet on the pgbench test case anyway.
Matteo, could you try it on
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Were you able to create a test case? I tried several things, including
stopping a backend in the middle of creating a MultiXactId, but no luck
yet.
I've had some success using Tatsuo's new scriptable pgbench:
Hmm. I wasn't able
Tom Lane wrote:
OK, I think this version may actually work, and get the wraparound
case right too. It hasn't failed yet on the pgbench test case anyway.
Matteo, could you try it on your test case?
Yes, it's working. The test case ran for a several minutes without errors.
Thank you all :)
Tom Lane [EMAIL PROTECTED] writes:
creatingOffsetZero will be a bool that gets set before releasing
MultiXactGenLock if offset 0 is being returned, and then we clear it
after updating the slru data structures if we had starting offset 0.
If you're going to have a special flag indicating this
Greg Stark [EMAIL PROTECTED] writes:
If you're going to have a special flag indicating this couldn't you just have
a special flag indicating that the offset isn't ready yet? Loop until that
flag is cleared instead of looking for offset != 0 at all.
Well, the whole idea didn't work anyway :-(.
Alvaro Herrera wrote:
Additionally, I can confirm that the problem doesn't manifest with your
latest patch. I'm running several instances just to be sure.
Ok, I tested several runs and the problem didn't manifest. Additionally
I tested that wraparound also worked on at least some cases, by
Hi,
I'm using 8.1beta4 on a development server for a rather db-intensive
application. This application has a multiprocess daemon which was
working fairly well in past. After some recent changes I started having
deadlock problems. While investigating to remove what was causing them I
removed
On Thu, Oct 27, 2005 at 10:59:30AM +0200, Matteo Beccati wrote:
Hi,
I'm using 8.1beta4 on a development server for a rather db-intensive
application. This application has a multiprocess daemon which was
working fairly well in past. After some recent changes I started having
deadlock
Hi Martijn,
Backtrace would be nice. I don't suppose your backend is compiled with
debugging? If so, try attaching to the backend and do:
break MemoryContextAlloc if size 10
Obviously something is trying to allocate and negative number of
bytes... 4291419108 = -3548188
Here is the
On Thu, Oct 27, 2005 at 11:37:09AM +0200, Matteo Beccati wrote:
Here is the backtrace, hoping I did it correctly:
Dagnammit. I was wondering if that was going to happen. If your
optimisation is up, the values of arguments to the functions don't
display right (look at the rest, they're obviously
Belay that, you should be able to put a breakpoint on errstart or elog
or perhaps errmsg. Much easier...
(I expected the find the answer in the developer FAQ, but it's not
there).
Hope this helps,
On Thu, Oct 27, 2005 at 12:04:45PM +0200, Martijn van Oosterhout wrote:
On Thu, Oct 27, 2005 at
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
Belay that, you should be able to put a breakpoint on errstart or elog
or perhaps errmsg. Much easier...
(I expected the find the answer in the developer FAQ, but it's not
there).
I removed it because it used to be in the main
On Thu, Oct 27, 2005 at 08:54:57AM -0400, Bruce Momjian wrote:
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
Belay that, you should be able to put a breakpoint on errstart or elog
or perhaps errmsg. Much easier...
(I expected the find the answer in the developer FAQ, but
Martijn van Oosterhout wrote:
Belay that, you should be able to put a breakpoint on errstart or elog
or perhaps errmsg. Much easier...
After several tries, I finally found a way to produce a reliable
backtrace :)
Breakpoint 4, errfinish (dummy=0) at elog.c:346
346
Martijn van Oosterhout kleptog@svana.org writes:
Hmm, depends. It's not asked often, that for sure. Yet everytime it
comes up I keep forgetting if I should be breaking on errstart, errmsg
or something else. One of these days I might just write it on a post-it
note next to my computer.
I
Matteo Beccati [EMAIL PROTECTED] writes:
(gdb) bt
#0 errfinish (dummy=0) at elog.c:346
#1 0x08265896 in elog_finish (elevel=20, fmt=0x831858c invalid memory
alloc request size %lu) at elog.c:930
#2 0x0827b5cf in MemoryContextAlloc (context=0x85b2238,
size=4279476584) at mcxt.c:505
#3
Hi Tom,
Well, this apparently indicates a bug in the new multixact code, but
there's not enough info here to figure out what went wrong. Can you
create a test case that will let someone else reproduce the problem?
Unfortunately the error pops up randomly in a very complex app/db and I
am
OK, developer's FAQ updated to mention errfinish,
---
Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
Hmm, depends. It's not asked often, that for sure. Yet everytime it
comes up I keep forgetting if I
On Thu, Oct 27, 2005 at 03:45:16PM +0200, Matteo Beccati wrote:
Hi Tom,
Well, this apparently indicates a bug in the new multixact code, but
there's not enough info here to figure out what went wrong. Can you
create a test case that will let someone else reproduce the problem?
Matteo Beccati wrote:
Hi Tom,
Well, this apparently indicates a bug in the new multixact code, but
there's not enough info here to figure out what went wrong. Can you
create a test case that will let someone else reproduce the problem?
Unfortunately the error pops up randomly in a very
Hi,
Go up a few levels to GetMultiXactIdMembers and type info locals, see
if we can get the values of some of the variables there. Also, if you
can turn the debugging down to -O0, that will make the results in gdb
much more reliable.
It's clear at least that length is negative, but what about
Hi Alvaro,
It would be good to see the contents of MultiXactState. I suspect
there's a race condition in the MultiXact code.
Good, but... where do I find the contents of MultiXactState? ;)
Best regards
--
Matteo Beccati
http://phpadsnew.com
http://phppgads.com
Matteo Beccati wrote:
Hi Alvaro,
It would be good to see the contents of MultiXactState. I suspect
there's a race condition in the MultiXact code.
Good, but... where do I find the contents of MultiXactState? ;)
Huh, it should be a global variable. Try
p *MultiXactState
--
Alvaro
Matteo Beccati wrote:
#2 0x0827b5cf in MemoryContextAlloc (context=0x856bcc8,
size=4278026492) at mcxt.c:505
__func__ = MemoryContextAlloc
#3 0x080b6a16 in GetMultiXactIdMembers (multi=320306, xids=0xbfbfaba4)
at multixact.c:935
pageno = 156
prev_pageno = 156
Hi Alvaro,
It would be good to see the contents of MultiXactState. I suspect
there's a race condition in the MultiXact code.
Good, but... where do I find the contents of MultiXactState? ;)
Huh, it should be a global variable. Try
p *MultiXactState
Done:
(gdb) p *MultiXactState
$1 =
Alvaro Herrera [EMAIL PROTECTED] writes:
I think the problem is that CreateMultiXactId calls
GetNewMultiXactId and then RecordNewMultiXact, and the lock is released
between the calls. So one backend could try to read the offset before
another one had the time to finish writing it.
Ugh, yes,
On Thu, Oct 27, 2005 at 10:23:07AM -0400, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
I think the problem is that CreateMultiXactId calls
GetNewMultiXactId and then RecordNewMultiXact, and the lock is released
between the calls. So one backend could try to read the offset
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
I don't see any easy way to fix this except by introducing a lot more
locking than is there now --- ie, holding the MultiXactGenLock until the
new mxact's starting offset has been written to disk. Any better ideas?
Well, it isn't a
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
I think the problem is that CreateMultiXactId calls
GetNewMultiXactId and then RecordNewMultiXact, and the lock is released
between the calls. So one backend could try to read the offset before
another one had the time to finish
Alvaro Herrera wrote:
I don't see any easy way to fix this except by introducing a lot more
locking than is there now --- ie, holding the MultiXactGenLock until the
new mxact's starting offset has been written to disk. Any better ideas?
Well, it isn't a very good solution because it requires
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
I confess being attracted to Martijn's idea of looping until the correct
answer is obtained. I don't think it's even too difficult to implement.
But I wonder if there's some hidden pitfall.
I've been looking at that and I think
Alvaro Herrera [EMAIL PROTECTED] writes:
The remaining question for me is, how do we sleep until the correct
offset has been stored?
I was thinking of just pg_usleep for some nominal time (1ms maybe)
and try to read the offsets page again. This is a corner case so
the performance doesn't have
Tom, Alvaro
The remaining question for me is, how do we sleep until the correct
offset has been stored?
I was thinking of just pg_usleep for some nominal time (1ms maybe)
and try to read the offsets page again. This is a corner case so
the performance doesn't have to be great.
Let me know
Tom Lane [EMAIL PROTECTED] writes:
We'd have to make sure zero is never the *correct* value of the offset,
but that just means wasting one word, which seems no problem.
In theory it's possible for only half the word to be written or even to have
outright garbage show up. In practice I think
Greg Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
We'd have to make sure zero is never the *correct* value of the offset,
but that just means wasting one word, which seems no problem.
In theory it's possible for only half the word to be written or even to have
outright
Matteo Beccati wrote:
Tom, Alvaro
The remaining question for me is, how do we sleep until the correct
offset has been stored?
I was thinking of just pg_usleep for some nominal time (1ms maybe)
and try to read the offsets page again. This is a corner case so
the performance doesn't have
Alvaro Herrera [EMAIL PROTECTED] writes:
Ok. I had hoped to reproduce the problem with pristine sources, in
order to verify that I was able to show it not appearing with my patch.
However I have been unable to create a situation in which the problem
appears. So I attach the patch that I came
I wrote:
I'm currently experimenting with an alternative approach, which leaves
the nextOffset arithmetic as it was and instead special-cases the zero
offset case this way:
Attached is a completed patch, which I've had no time to test yet, but
I have to leave for the evening right now --- so
43 matches
Mail list logo
