Обсуждение: 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