>
> > I have a production server with Postgres 6.4.2.
> > Seems 6.4.2 has problems on linux. Dump file is small (30K in
> > bzip2) - I can send it if someone want to try to reproduce it.
>
> Yes, send me the file. Unless gzip is *much* larger, please send in that
> format.
I'm already on it and seem's I've found the problem.
Oleg is using a database schema with check constraints (which
are executed during COPY FROM). The function ExecRelCheck()
parses each constraint for each tuple every time with
stringToNode().
First this is wasted efford, second only the outermost node
of the qualification tree built with stringToNode() is
pfree()'d in the loop. Without debugging it I can tell that
a simple constraint like 'attr != 0' will produce an Expr
pointing to an Oper and a List with one Var and another
Const. So only one of 4 palloc()'d nodes is pfree()'d, the
other 3 hang aroung until transaction end.
But it's a little wired here and we cannot put the constraint
qual-trees into the Relation structure for a long time. This
will later cause these nodes hang around in the Cache context
where they shouldn't. Don't know how to optimize here yet.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #
