Karl Denninger wrote:
The problem is that I was holding the ts_vector in a column in the table
with a GIST index on that column. This fails horribly under 8.3; it
appears to be ok on the reload but as there is a trigger on updates any
update or insert fails immediately with a data mistype
Richard Huxton wrote:
Karl Denninger wrote:
The problem is that I was holding the ts_vector in a column in the
table with a GIST index on that column. This fails horribly under
8.3; it appears to be ok on the reload but as there is a trigger on
updates any update or insert fails
Karl Denninger wrote:
Richard Huxton wrote:
Karl Denninger wrote:
The problem is that I was holding the ts_vector in a column in the
table with a GIST index on that column. This fails horribly under
8.3; it appears to be ok on the reload but as there is a trigger on
updates any update or
I can reproduce this as I have the dump from before conversion and can
load it on a different box and make it happen a second time.
Would you like it on the list or privately?
Karl Denninger ([EMAIL PROTECTED])
http://www.denninger.net
Richard Huxton wrote:
Karl Denninger wrote:
Richard
Karl Denninger wrote:
I can reproduce this as I have the dump from before conversion and can
load it on a different box and make it happen a second time.
Would you like it on the list or privately?
Privately, unless you can boil it down to a small schema fragment.
--
Richard Huxton
Ugh.
I am attempting to move from 8.2.6 to 8.3, and have run into a major
problem.
The build goes fine, the install goes fine, the pg_dumpall goes fine.
However, the reload does not. I do the initdb and then during the
reload I get thousands of errors, apparently from table data which is
On Sun, Mar 2, 2008 at 1:41 PM, Karl Denninger [EMAIL PROTECTED] wrote:
Ugh.
I am attempting to move from 8.2.6 to 8.3, and have run into a major
problem.
The build goes fine, the install goes fine, the pg_dumpall goes fine.
However, the reload does not. I do the initdb and then
A whole host of them, mostly about bad data formats in some of the table
data. I suspect the underlying problem is that something got mangled in
the table creates.
I'm setting up on a different box as my attempt to create a second
instance failed horribly - compiling with a different prefix
Scott Marlowe wrote:
On Sun, Mar 2, 2008 at 1:41 PM, Karl Denninger [EMAIL PROTECTED] wrote:
Ugh.
I am attempting to move from 8.2.6 to 8.3, and have run into a major
problem.
The build goes fine, the install goes fine, the pg_dumpall goes fine.
However, the reload does not. I do the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sun, 02 Mar 2008 15:46:25 -0600
Karl Denninger [EMAIL PROTECTED] wrote:
I'm not quite clear what I have to do in terms of if/when I can drop
the old tsearch config stuff and for obvious reasons (like not
running into this in the future) I'd
Karl Denninger [EMAIL PROTECTED] writes:
It looks like the problem had to do with the tsearch2 module that I have
in use in a number of my databases, and which had propagated into
template1, which meant that new creates had it in there.
The old tsearch2 module isn't at all compatible with
Tom Lane wrote:
Karl Denninger [EMAIL PROTECTED] writes:
It looks like the problem had to do with the tsearch2 module that I have
in use in a number of my databases, and which had propagated into
template1, which meant that new creates had it in there.
The old tsearch2 module isn't
Joshua D. Drake wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sun, 02 Mar 2008 15:46:25 -0600
Karl Denninger [EMAIL PROTECTED] wrote:
I'm not quite clear what I have to do in terms of if/when I can drop
the old tsearch config stuff and for obvious reasons (like not
running into
13 matches
Mail list logo
