Re: "invalid memory alloc request size " in deferred trigger causes transaction to fail, but the backend keeps running
От | Frank van Vugt |
---|---|
Тема | Re: "invalid memory alloc request size |
Дата | |
Msg-id | 200412022151.42120.ftm.van.vugt@foxi.nl обсуждение исходный текст |
Ответ на |
Re: "invalid memory alloc request size |
Ответы |
Re: "invalid memory alloc request size |
Список | pgsql-bugs |
> > I'm wondering > > about the best way to proceed in order to produce some helpfull input to > > the developers. > > Provide a reproducible test case maybe? Sorry, won't be that easy. I didn't encounter the problem with earlier (smaller) data-sets and even if I would put in the hours needed in order to strip the schema and change the conversion tool both with the uncertainty that I'd be reproducing the proper sequence of (trigger) events, I wouldn't be able to provide the dataset itself (i.e. non-disclosure) > Also, building with --enable-cassert might help track it down. Will do that for starters. Hold on, I thought that this error message would be generated from numerous places in the code but it isn't. I'll recompile with debugging enabled and put breakpoints on the appropriate lines to produce a backtrace. <some work is done> Ok, using --enable-cassert might not be such a good idea for now, since it triggers a trap very early on in the conversion: TRAP: FailedAssertion("!(((ntp)->t_data)->t_infomask & 0x0010)", File: "catcache.c", Line: 1729) So for now I have disabled assertions again and will focus on creating the backtrace for the memory alloc problem first. When needed / wanted I can always try and go over any assertion failures later. Will be able to post a backtrace in a few hours, I hope. -- Best, Frank.
В списке pgsql-bugs по дате отправления: