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 00:50:35 |
Message-ID: | 200412030150.35420.ftm.van.vugt@foxi.nl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
> > I could reproduce this case tomorrow and inspect some variables or call
> > abort() if you think that could be of any help?
>
> Do you have hardware watchpoints on that machine?
Mmm, don't know for sure, will have a look tomorrow.
> What I'd be inclined
> to try is tracing through the transaction to see where
> SerializableSnapshotData.xcnt or LatestSnapshotData.xcnt gets clobbered
> from. It'd be mighty tedious if you have to fall back on a software
> watchpoint though.
A hint on the expression(s) to use would be appreciated !
> Also, I gather from the xact.c traceback that the transaction looks like
>
> begin;
> savepoint a;
> ...
> commit; -- without releasing the savepoint
>
> Does anything happen before the SAVEPOINT?
Actually, the SQL involved is v7.4.6, so there are no savepoints to begin with
(or arguably, there's nothing 'before' a savepoint ;))
> Now that you see which plpgsql function is failing, do you have a better
> shot at making a self-contained example?
Not really, but if tracing the transaction won't reveal anything else I guess
I will have no choice..... ;-(
--
Best,
Frank.
From | Date | Subject | |
---|---|---|---|
Next Message | Frank van Vugt | 2004-12-03 00:55:43 | Re: "invalid memory alloc request size <n>" in deferred trigger causes transaction to fail, but the backend keeps running |
Previous Message | Frank van Vugt | 2004-12-03 00:27:19 | Re: "invalid memory alloc request size <n>" in deferred trigger causes transaction to fail, but the backend keeps running |