This a technique employed with great success by OpenBSD. Theo de Raadt says, "Can you imagine if a Boeing engineer didn't fix all instances of a wiring flaw?"
When I was learning Haskell, I actually was able to answer no to this question. The Array  data type in Haskell lets (requires) you to specify the bounds (upper and lower) when you create a new Array, and I ended up mixing 0 indexed and 1 indexed arrays throughout my program.
 Which you should almost never use. Use Data.Vector or Data.Sequence instead.
int *x = malloc(sizeof(int)*100);
x = x + 50;
x[-10] = 1337;
But actually I remember that it can occasionally be used in image processing too, when you would use a pointer to iterate through an image, I would routinely use things like
dx = *(ptr+1)-*(ptr-1);
dx = ptr - ptr[-1];
I can imagine myself hunched over my keyboard at 3am swearing quietly and trying to figure out why the hell this is happening to me right now.
It's often helpful to know who did it and have that person involved in fixing it and looking for other cases since they're likely to know that area of the code and best understand the thought process that ended up there.
However, it should never be done with any sort of 'blame' or 'fault'. It's something to handle with care.
Of course, one of the other great things about code review is that it diffuses blame, and allows us to focus on other things. If Dev A introduced a bug even after Dev B reviewed the code, then the root problem isn't that Dev A is a dummy.
One needs some openness to changing process to prevent future bugs; process questions are a key part of a postmortem.
Personally I always want to know if something I did has affected people in whatever way so that I can learn from it.