Jeremy Drake <[EMAIL PROTECTED]> writes: > I ran without that function you made, and it got the error, but not a > crash. I stuck an Assert(false) right before the ereport for that > particular error, and I did end up with a core there, but I don't see > anything out of the ordinary (what little I know of the ordinary ;)
Yeah, that's just the CREATE TEMP TABLE doing what it's supposed to do. The problem is presumably that a prior DROP operation failed to remove the pg_type row associated with a previous temp table of the same name ... but why that would happen is still really unclear. Does your application drop these temp tables explicitly, or leave them to be dropped automatically during commit? It might be interesting to see whether changing that makes any difference. I'm also curious whether the transaction that makes the temp table is ever rolled back instead of committed. 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