I agree about keeping it simple for the users. Anyway if that
shows up a bad problems with either the implementation or the
operating system of the users it would be nice to know how
to inspect it further. In my case this could also help
debugging a postgres extension (postgis) which is involved
strk [EMAIL PROTECTED] writes:
The question now is: what does that message mean ?
It means that the magic number that should be on the first page of the
btree index isn't right. We can deduce that something has clobbered the
first page of the index, but guessing what and how requires much more
Tom Lane wrote:
strk [EMAIL PROTECTED] writes:
The question now is: what does that message mean ?
It means that the magic number that should be on the first page of the
btree index isn't right. We can deduce that something has clobbered the
first page of the index, but guessing what and how
On Tue, 2003-12-09 at 20:19, Jan Wieck wrote:
Christopher Kings-Lynne wrote:
I couldn't agree more. Look at this very instance. He now found the
right reindex command and the corrupted file is gone. We don't have the
slightest clue what happened to that file. Was it truncated? Did some
Tom Lane wrote:
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Is there anything stopping us going through the code and finding all
ereports that can be fixed by a REINDEX, and issue a HINT with all of
them saying that they should REINDEX the broken index?
How would you know which ones
Jan Wieck wrote:
Tom Lane wrote:
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Is there anything stopping us going through the code and finding all
ereports that can be fixed by a REINDEX, and issue a HINT with all of
them saying that they should REINDEX the broken index?
How
I couldn't agree more. Look at this very instance. He now found the
right reindex command and the corrupted file is gone. We don't have the
slightest clue what happened to that file. Was it truncated? Did some
other process scribble around in the shared memory? How do you tell now?
The end user
Christopher Kings-Lynne wrote:
I couldn't agree more. Look at this very instance. He now found the
right reindex command and the corrupted file is gone. We don't have the
slightest clue what happened to that file. Was it truncated? Did some
other process scribble around in the shared memory?
I get the following error when vacuuming a db or inserting
a big value in a column of a toastable datatype (GEOMETRY).
ERROR: Index pg_toast_8443892_index is not a btree
My last action has been killing a psql that was getting
mad about receiving too much input and beeping as hell
strk wrote:
I get the following error when vacuuming a db or inserting
a big value in a column of a toastable datatype (GEOMETRY).
ERROR: Index pg_toast_8443892_index is not a btree
My last action has been killing a psql that was getting
mad about receiving too much input and beeping as hell
JanWieck wrote:
strk wrote:
I get the following error when vacuuming a db or inserting
a big value in a column of a toastable datatype (GEOMETRY).
ERROR: Index pg_toast_8443892_index is not a btree
My last action has been killing a psql that was getting
mad about receiving
strk wrote:
JanWieck wrote:
strk wrote:
I get the following error when vacuuming a db or inserting
a big value in a column of a toastable datatype (GEOMETRY).
ERROR: Index pg_toast_8443892_index is not a btree
My last action has been killing a psql that was getting
mad about receiving
strk [EMAIL PROTECTED] writes:
gis=# reindex table pg_toast_8443892; -- this was an assuption I made
ERROR: Relation pg_toast_8443892 does not exist
If it's 7.3 or later you need to say
reindex table pg_toast.pg_toast_8443892;
regards, tom lane
tgl wrote:
strk [EMAIL PROTECTED] writes:
gis=# reindex table pg_toast_8443892; -- this was an assuption I made
ERROR: Relation pg_toast_8443892 does not exist
If it's 7.3 or later you need to say
reindex table pg_toast.pg_toast_8443892;
regards, tom lane
It
I get the following error when vacuuming a db or inserting
a big value in a column of a toastable datatype (GEOMETRY).
ERROR: Index pg_toast_8443892_index is not a btree
My last action has been killing a psql that was getting
mad about receiving too much input and beeping as hell
(readline
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Is there anything stopping us going through the code and finding all
ereports that can be fixed by a REINDEX, and issue a HINT with all of
them saying that they should REINDEX the broken index?
How would you know which ones correspond to
16 matches
Mail list logo
