Well!
Indeed the problem *was* with the data (I know; assuming makes and
ass...) I had assumed the data I was importing was that which had been
pg_dumped from the 7.1.3 db and so was "correct".
It turns out that after the pg_dump it had been processed though a perl
script to:
1) convert the string ":60.00" to ":59.99" - pg_dump had a bug with
roundoff of seconds and psql would choke trying to set a time
with a seconds value of 60
2) convert the old style col. default of 'timestamp(now())' to
CURRENT_TIMESTAMP
However - some of our tables contain data with embedded ^M's (ASCII 13)
(because they're being populated from a web page.)
Well, the perl script would interpret the ^M as a newline and end up
converting the two lines:
114<TAB>3<TAB>re: Updates<TAB>Can you read over^M\
the help files?<TAB>6523
to three lines:
114<TAB>3<TAB>re: Updates<TAB>Can you read over
\
the help files?<TAB>6523
so the first line would have truncated data, and the second line would
continue the mess.
This would obviously cause problems during import.
What I can't figure out is why it would kill the back-end (and usually
end up making the OS (Linux 7.3) unstable). I've been trying to make a
small example that repeatably shows this but of course it won't crash!
It just (properly) give's a "Fail to add null" error.
I'm going to try and make a more complex setup to get this thing to
"reliably" cause the crash because it seems there's a bug in here
somewhere. I'll post that when I get it.
So anyways... for those of you out there migrating up where you process
the dump before psql db < dumpfile - watch out for embedded ^Ms!
thanks,
-Steve
