pgsql: Improve a number of elog messages for not-supposed-to-happen
Log Message:
-----------
Improve a number of elog messages for not-supposed-to-happen cases in btrees,
since these seem to happen after all in corrupted indexes. Make sure we
supply the index name in all cases, and provide relevant block numbers where
available. Also consistently identify the index name as such.
Back-patch to 8.2, in hopes that this might help Mason Hale figure out his
problem.
Modified Files:
--------------
pgsql/src/backend/access/nbtree:
nbtinsert.c (r1.162 -> r1.163)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/nbtree/nbtinsert.c?r1=1.162&r2=1.163)
nbtpage.c (r1.104 -> r1.105)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/nbtree/nbtpage.c?r1=1.104&r2=1.105)
nbtsearch.c (r1.114 -> r1.115)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/nbtree/nbtsearch.c?r1=1.114&r2=1.115)
On Mon, 2007-12-31 at 04:52 +0000, Tom Lane wrote:
Log Message:
-----------
Improve a number of elog messages for not-supposed-to-happen cases in btrees,
since these seem to happen after all in corrupted indexes. Make sure we
supply the index name in all cases, and provide relevant block numbers where
available. Also consistently identify the index name as such.Back-patch to 8.2, in hopes that this might help Mason Hale figure out his
problem.
Would it be helpful to do this for duplicate row detection as well?
It would be great to get the htids of the two duplicates when we do
detect this situation.
--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com
Simon Riggs <simon@2ndquadrant.com> writes:
Would it be helpful to do this for duplicate row detection as well?
It would be great to get the htids of the two duplicates when we do
detect this situation.
99.999% of the time it would be confusing gibberish :-(. That's a very
ordinary user-facing error message, remember.
If we had a way to know that a particular occurrence represented a
(seemingly) internal problem rather than run-of-the-mill user error,
then yeah, but I don't see how we'd know that.
regards, tom lane