Обсуждение: pgsql: Improve a number of elog messages for not-supposed-to-happen
pgsql: Improve a number of elog messages for not-supposed-to-happen
От
tgl@postgresql.org (Tom Lane)
Дата:
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