Matt Magoffin <postgresql.org@msqr.us> writes: > Sorry if I left any relavent details out. I've been looking at this for > a while so many things are probably obvious only to me. Could you hint > at which additional details you think would be useful here? What I asked for was a self-contained example with which someone else could reproduce the problem. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend

"Matt Magoffin" <postgresql.org@msqr.us> writes: > I understand. I cannot make the SELECT query nor the ADD INDEX command > break on an empty database. I cannot share this database data, either. So try to make a test case using dummy data, or with suitably obscured versions of your real data. Also, consider compiling a debug-enabled build and showing us a gdb stack trace from the core dump. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster

"Matt Magoffin" <postgresql.org@msqr.us> writes: > (gdb) bt > #0 0xffff8820 in __memcpy () > #1 0x004d9098 in xmlBufferAdd () > #2 0x004e0dc4 in xmlParserInputBufferCreateMem () > #3 0x004ced98 in xmlCtxtReadMemory () > #4 0x0026ea0c in xpath (fcinfo=0x37) at xml.c:3183 > #5 0x001095bc in ExecMakeFunctionResultNoSets (fcache=0x10563fc, > econtext=0x10562a8, isNull=0xbfffd4f8 "\004Y?P", isDone=0x0) at > execQual.c:1412 [ squint... ] Hmm, that seems to be in the same general area as some post-beta2 fixes. Before we spend more time on this, could you update to 8.3beta3 and see if the problem is still there? b3 is not officially announced yet, but the tarballs are up. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend

"Matt Magoffin" <postgresql.org@msqr.us> writes: > I took the latest snapshot from /dev, but I still get the same crash: Drat :-(. Please try a bit harder at generating a self-contained test case. Given where the crash is happening, I suspect it may be only weakly if at all dependent on your input data, so you may not need to work that hard at generating dummy data. In any case it's unlikely to depend much on the content (as opposed to the XML structure) of your data, so possibly you could sanitize your real data sufficiently by stripping out everything but the XML tags. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend

"Matt Magoffin" <postgresql.org@msqr.us> writes: > Hmm. I do have a load testing program with which I _might_ be able to get > to generate a sufficient amount of dummy data. However, it apparently will > require many tens of thousands of rows to reproduce the problem. Will I be > able to post a dump file from this table somewhere? I don't have a public > server I could host it from. You could email it to me off-list, as long as it doesn't come to more than say a few tens of megabytes (don't forget the possibility of compressing the dump). regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster