From: | Frank van Vugt <ftm(dot)van(dot)vugt(at)foxi(dot)nl> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-bugs <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: "invalid memory alloc request size <n>" in deferred trigger causes transaction to fail, but the backend keeps running |
Date: | 2004-12-03 15:26:08 |
Message-ID: | 200412031626.08743.ftm.van.vugt@foxi.nl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
> > Meanwhile, one of the application developers here bumped into a way to
> > reproduce what looks like the same memory alloc problem (exactly the same
> > point in exactly the same trigger) using our application software
> > only,
>
> Oh good. Can you construct a self-contained test case then?
Will try to do just that when the rest won't work.
> > All were located at sinval.c:888
>
> This is the expected case. The failure in CopySnapshot has got to
> indicate that somebody set one or the other field to some bizarrely
> large value, though. I take it you didn't run the watchpointed backend
> far enough to get the memory-alloc error?
Oh, but I did.....
All the breaks are at sinval.c:888 and at some point the memory-alloc simply
occurs. Do you mean you want a backtrace of the last break at line 888 just
before the error ?
--
Best,
Frank.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-12-03 15:50:54 | Re: "invalid memory alloc request size <n>" in deferred trigger causes transaction to fail, but the backend keeps running |
Previous Message | Tom Lane | 2004-12-03 15:17:40 | Re: "invalid memory alloc request size <n>" in deferred trigger causes transaction to fail, but the backend keeps running |