|
Home > Archive > PostgreSQL Hacks > October 2005 > Re: ERROR: invalid memory alloc request size <a_big_number_here>
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: ERROR: invalid memory alloc request size <a_big_number_here>
|
|
| Tom Lane 2005-10-27, 9:26 am |
| Matteo Beccati <php@beccati.com> 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 0x080b6a16 in GetMultiXactIdMember
s (multi=301994, xids=0xbfbfaba4)
> at multixact.c:935
> #4 0x080b6271 in MultiXactIdIsRunning
(multi=301994) at multixact.c:373
> #5 0x0828347d in HeapTupleSatisfiesUp
date (tuple=0x28ccbb40, curcid=13,
> buffer=756) at tqual.c:620
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?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
| |
| Matteo Beccati 2005-10-27, 9:26 am |
| 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 unable to produce a test case :(
Lat me know what other I can do to help fixing the bug.
Best regards
--
Matteo Beccati
http://phpadsnew.com
http://phppgads.com
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
| |
| Martijn van Oosterhout 2005-10-27, 9:26 am |
| On Thu, Oct 27, 2005 at 03:45:16PM +0200, Matteo Beccati wrote:
> Hi Tom,
>
>
> Unfortunately the error pops up randomly in a very complex app/db and I
> am unable to produce a test case :(
Go up a few levels to GetMultiXactIdMember
s 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 the other
variables...
Do you use a lot of subtransactions, function, savepoints, anything
like that?
Hope this helps,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.
| |
| Alvaro Herrera 2005-10-27, 9:26 am |
| Matteo Beccati wrote:
> Hi Tom,
>
>
> Unfortunately the error pops up randomly in a very complex app/db and I
> am unable to produce a test case :(
>
> Lat me know what other I can do to help fixing the bug.
It would be good to see the contents of MultiXactState. I suspect
there's a race condition in the MultiXact code.
--
Alvaro Herrera Valdivia, Chile ICBM: S 39º 49' 17.7", W 73º 14' 26.8"
"El realista sabe lo que quiere; el idealista quiere lo que sabe" (Anónimo)
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
| |
| Matteo Beccati 2005-10-27, 9:26 am |
| Hi,
> Go up a few levels to GetMultiXactIdMember
s 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 the other
> variables...
I already recompiled all with -O0 to be sure that I was able to have a
backtrace. This is the full bt:
#2 0x0827b5cf in MemoryContextAlloc (context=0x856bcc8,
size=4278026492) at mcxt.c:505
__func__ = "MemoryContextAlloc"
#3 0x080b6a16 in GetMultiXactIdMember
s (multi=320306, xids=0xbfbfaba4)
at multixact.c:935
pageno = 156
prev_pageno = 156
entryno = 819
slotno = 2
offptr = (MultiXactOffset *) 0x286536ac
offset = 4235201
length = -4235201
i = 138425096
nextMXact = 320308
tmpMXact = 320307
nextOffset = 4235265
ptr = (TransactionId *) 0xbfbfab78
> Do you use a lot of subtransactions, function, savepoints, anything
> like that?
I just removed a subtransaction that I put in a function that was used
to capture the deadlock errors. That subtransaction was actually useless
because I removed the FOR UPDATE clause that was causing the deadlock,
but the alloc error is still there. I'll try to search through the code
to find some other subtransactions.
Best regards
--
Matteo Beccati
http://phpadsnew.com
http://phppgads.com
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
| |
| Matteo Beccati 2005-10-27, 9:26 am |
| 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
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
| |
| Alvaro Herrera 2005-10-27, 9:26 am |
| Matteo Beccati wrote:
> Hi Alvaro,
>
>
> Good, but... where do I find the contents of MultiXactState? ;)
Huh, it should be a global variable. Try
p *MultiXactState
--
Alvaro Herrera http://www.amazon.com/gp/registry/5ZYLFMCVHXC
"Aprender sin pensar es inútil; pensar sin aprender, peligroso" (Confucio)
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
| |
| Alvaro Herrera 2005-10-27, 9:26 am |
| Matteo Beccati wrote:
> #2 0x0827b5cf in MemoryContextAlloc (context=0x856bcc8,
> size=4278026492) at mcxt.c:505
> __func__ = "MemoryContextAlloc"
> #3 0x080b6a16 in GetMultiXactIdMember
s (multi=320306, xids=0xbfbfaba4)
> at multixact.c:935
> pageno = 156
> prev_pageno = 156
> entryno = 819
> slotno = 2
> offptr = (MultiXactOffset *) 0x286536ac
> offset = 4235201
> length = -4235201
> i = 138425096
> nextMXact = 320308
> tmpMXact = 320307
> nextOffset = 4235265
> ptr = (TransactionId *) 0xbfbfab78
Whoa. length = *offptr - offset, which means that the datum stored at
offptr is 0. 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.
--
Alvaro Herrera Developer, http://www.PostgreSQL.org
"No single strategy is always right (Unless the boss says so)"
(Larry Wall)
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
| |
| Matteo Beccati 2005-10-27, 9:26 am |
| Hi Alvaro,
>
> Huh, it should be a global variable. Try
>
> p *MultiXactState
Done:
(gdb) p *MultiXactState
$1 = {nextMXact = 320308, nextOffset = 4235265, lastTruncationPoint =
302016, perBackendXactIds = {0}}
Best regards
--
Matteo Beccati
http://phpadsnew.com
http://phppgads.com
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
| |
| Tom Lane 2005-10-27, 5:29 pm |
| Alvaro Herrera <alvherre@alvh.no-ip.org> 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, that is clearly a hole :-( even if it turns out not to explain
Matteo's observation.
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?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
| |
| Martijn van Oosterhout 2005-10-27, 5:29 pm |
| On Thu, Oct 27, 2005 at 10:23:07AM -0400, Tom Lane wrote:
> Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
>
> Ugh, yes, that is clearly a hole :-( even if it turns out not to explain
> Matteo's observation.
>
> 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?
I don't see immediatly if it's feasible or not. But another approach is
to detect when it happened, and retry. Parts of the buffer code do this
for example...
Hope this helps,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.
| |
| Alvaro Herrera 2005-10-27, 5:29 pm |
| Tom Lane wrote:
> Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
>
> Ugh, yes, that is clearly a hole :-( even if it turns out not to explain
> Matteo's observation.
>
> 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 us to retain the
MultiXactGenLock past a XLogInsert and some I/O on SLRU pages.
Previously the lock was mostly only used in short operations and very
rarely held during I/O. But I don't see any other solution either.
Patch attached.
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.
Thanks to Matteo for finding the bug!
--
Alvaro Herrera http://www.PlanetPostgreSQL.org
"El número de instalaciones de UNIX se ha elevado a 10,
y se espera que este número aumente" (UPM, 1972)
| |
| Tom Lane 2005-10-27, 5:29 pm |
| Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> Tom Lane wrote:
[color=darkred]
> Well, it isn't a very good solution because it requires us to retain the
> MultiXactGenLock past a XLogInsert and some I/O on SLRU pages.
Yeah :-(. If MultiXactGenLock wasn't a bottleneck before, it will soon
become one.
> 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 it can work. The key point is
that GetNewMultiXactId() does guarantee that space has been allocated
for the new mxact's offset before it releases the lock (else we'd risk
trying to read a nonexistent slru page when we fetch the offset in
GetMultiXactIdMember
s). And we are careful to zero out newly allocated
space. So it should be safe to assume that the offset will be zero if
it hasn't been initialized yet. So we could loop if we see zero.
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.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql
.org so that your
message can get through to the mailing list cleanly
| |
| Matteo Beccati 2005-10-27, 5:29 pm |
| Alvaro Herrera wrote:
>
> Well, it isn't a very good solution because it requires us to retain the
> MultiXactGenLock past a XLogInsert and some I/O on SLRU pages.
> Previously the lock was mostly only used in short operations and very
> rarely held during I/O. But I don't see any other solution either.
> Patch attached.
The patch works wonderfully. I'm trying to stress the whole app and with
no errors until now.
> Thanks to Matteo for finding the bug!
Thanks to you all for helping out and fixing it :)
Best regards
--
Matteo Beccati
http://phpadsnew.com
http://phppgads.com
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql
.org so that your
message can get through to the mailing list cleanly
| |
| Matteo Beccati 2005-10-27, 5:29 pm |
| Tom, Alvaro
>
> 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 if you need to test some other patches.
Again, thank you
Best regards
--
Matteo Beccati
http://phpadsnew.com
http://phppgads.com
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql
.org so that your
message can get through to the mailing list cleanly
| |
| Alvaro Herrera 2005-10-27, 5:29 pm |
| Tom Lane wrote:
> Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
>
> I've been looking at that and I think it can work. The key point is
> that GetNewMultiXactId() does guarantee that space has been allocated
> for the new mxact's offset before it releases the lock (else we'd risk
> trying to read a nonexistent slru page when we fetch the offset in
> GetMultiXactIdMember
s).
The remaining question for me is, how do we sleep until the correct
offset has been stored?
--
Alvaro Herrera http://www.advogato.org/person/alvherre
"Nunca se desea ardientemente lo que solo se desea por razón" (F. Alexandre)
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
| |
| Tom Lane 2005-10-27, 5:29 pm |
| Alvaro Herrera <alvherre@alvh.no-ip.org> 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 to be great.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
| |
| Tom Lane 2005-10-27, 5:29 pm |
| Greg Stark <gsstark@mit.edu> writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
[color=darkred]
> 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 there are no actual
> architectures where this can really happen though.
Not an issue, because we have a lock around the read or write of the
slru buffer page. The problem is that there's no lock continuously held
through the creation of a multixact entry, and we don't really wish to
add one ...
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
| |
| Alvaro Herrera 2005-10-27, 5:29 pm |
| Matteo Beccati wrote:
> Tom, Alvaro
>
>
> Let me know if you need to test some other patches.
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 up with. Please test it.
I added a loop counter, to verify that we don't loop indefinitely. I'm
not sure that it's the best way to do it, but I'm too coward to leave it
without any check.
--
Alvaro Herrera Developer, http://www.PostgreSQL.org
"La soledad es compañía"
| |
| Tom Lane 2005-10-27, 8:23 pm |
| Alvaro Herrera <alvherre@alvh.no-ip.org> 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 up with. Please test it.
On further reflection, this isn't gonna work :-(. The problem with the
waste-a-slot approach is that it creates an ambiguity near the offsets
wraparound point: if you are looking at an mxid with starting offset
just under 2^32, and you see the next mxid has start offset 1, did your
mxid include the xid in offset 0 or not?
We could possibly fix that by decreeing that wrapped-around mxids never
use slot 0, but it seems pretty darn messy: that would affect fetching
and storing loops as well as the code that allocates space.
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:
* 2. The next multixact may still be in process of being filled in:
* that is, another process may have done GetNewMultiXactId but not yet
* written the offset entry for that ID. In that scenario, it is
* guaranteed that the offset entry for that multixact exists (because
* GetNewMultiXactId won't release MultiXactGenLock until it does)
* but contains zero (because we are careful to pre-zero offset pages).
* So, if we read zero as the next multixact offset, we have to treat
* it with suspicion. It could be valid, though. We deal with this
* ambiguity by requiring processes that are creating a multixact with
* starting offset zero to set the creatingOffsetZero flag in the shared
* data structure; we sleep until we see that cleared before trusting
* a zero offset. This is all pretty messy, but the mess occurs only
* in infrequent corner cases, so it seems better than holding the
* MultiXactGenLock for a long time on every multixact creation.
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.
Thoughts?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
| |
| Matteo Beccati 2005-10-28, 3:24 am |
| 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 be an alternative to it.
Unfortunately it doesn't solve the invalid alloc request issue.
Should I try Alvaro's second patch that you said not going to work?
Best regards
--
Matteo Beccati
http://phpadsnew.com
http://phppgads.com
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
| |
| Matteo Beccati 2005-10-28, 7:23 am |
| 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 broadcast)---------------------------
TIP 6: explain analyze is your friend
| |
| Alvaro Herrera 2005-10-28, 11:24 am |
| Tom Lane wrote:
> Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
>
> On further reflection, this isn't gonna work :-(. The problem with the
> waste-a-slot approach is that it creates an ambiguity near the offsets
> wraparound point: if you are looking at an mxid with starting offset
> just under 2^32, and you see the next mxid has start offset 1, did your
> mxid include the xid in offset 0 or not?
This is certainly a problem, but I think we can just assume that it did
and cope later with the possibility that it didn't. Which means that we
should allow GetMultiXactIdMember
s() check whether one element is
InvalidTransactionId
, and skip it if so. (AFAICS this should only happen
if the MultiXact members ends just before offset 0).
> 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:
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?
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.
--
Alvaro Herrera http://www.advogato.org/person/alvherre
"La Primavera ha venido. Nadie sabe como ha sido" (A. Machado)
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
| |
| Alvaro Herrera 2005-10-28, 11:24 am |
| Matteo Beccati wrote:
> Hi,
>
>
> 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 probability. So your original problem is
fixed, but there's still a bug.
--
Alvaro Herrera Developer, http://www.PostgreSQL.org
"Just treat us the way you want to be treated + some extra allowance
for ignorance." (Michael Brusser)
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
| |
| Tom Lane 2005-10-28, 11:24 am |
| Alvaro Herrera <alvherre@alvh.no-ip.org> 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 was last
night. Your idea of handling the wraparound ambiguity by ignoring
InvalidTransactionId
isn't bad --- I'll take a look at that.
> 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:
create table t1(f1 int);
insert into t1 select * from generate_series(1,10
00);
create file tscript containing
\setrandom n 1 1000
select * from t1 limit :n for share;
and do, say,
pgbench -c 10 -t 10000 -n -f tscript regression
Using CVS tip, this generates failures within a few seconds for me.
If it doesn't for you, try altering the number of processes (-c) and
the setrandom bounds.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql
.org so that your
message can get through to the mailing list cleanly
| |
| Alvaro Herrera 2005-10-28, 1:24 pm |
| Tom Lane wrote:
> Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
>
> I've had some success using Tatsuo's new scriptable pgbench:
Hmm. I wasn't able to reproduce it with this on my desktop machine, but
maybe it's because it's slow as hell. I plugged my notebook however and
I was able to.
Additionally, I can confirm that the problem doesn't manifest with your
latest patch. I'm running several instances just to be sure.
Thanks,
--
Alvaro Herrera http://www.advogato.org/person/alvherre
"Acepta los honores y aplausos y perderás tu libertad"
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
| |
| Matteo Beccati 2005-10-28, 1:24 pm |
| 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 :)
Best regards
--
Matteo Beccati
http://phpadsnew.com
http://phppgads.com
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
| |
| Greg Stark 2005-10-28, 1:24 pm |
| Tom Lane <tgl@sss.pgh.pa.us> 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 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.
--
greg
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
| |
| Tom Lane 2005-10-28, 1:24 pm |
| Greg Stark <gsstark@mit.edu> 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 :-(. But I think your proposal
is equivalent to holding the lock throughout CreateMultiXactId, which is
exactly what we're trying to avoid doing ...
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
| |
| Alvaro Herrera 2005-10-28, 1:24 pm |
| 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 doing
pg_resetxlog -O 4294967200 $PGDATA
dd if=/dev/zero of=$PGDATA/pg_multixact/members/FFFF bs=8192 count=32
and retrying the test. I did this several times, with no problems
detected.
--
Alvaro Herrera http://www.amazon.com/gp/registry/DXLWNGRJD34J
"Hay quien adquiere la mala costumbre de ser infeliz" (M. A. Evans)
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
|
|
|
|
|