Re: BUG #8470: 9.3 locking/subtransaction performance regression

Alvaro Herrera wrote:

> > What's the test coverage for these cases? It better be 110%...
>
> 110% is rather hard to achieve, particularly because of the cases
> involving crashed transactions. Other than that I think I tested all
> those paths. I will go through it again.

Actually, there was a nasty bug in that formulation of the patch; in
heap_lock_tuple I mixed the "is multi" case in with the "do we own a
lock" check, which are completely unrelated and cause a number of
regressions in isolation tests. Here's a reworked version. I removed
those new labels and gotos; seems better this way.

Note there are some new blocks that need to be reflowed and pgindented;
also the diff contain some spurious whitespace changes that are undoing
some pgindent decisions. There are also some spurious changes which
have to do with a later patch I have -- the one that optimizes for
LOCK_ONLY multis. I tried to avoid including unnecessary whitespace
changes so that the actual code changes are easier to spot, but if I was
to remove them all I wouldn't have been able to submit the patch this
year, so please bear with me.

I generated the "make coverage" report after having run initdb, the
isolation tests and the regular regression tests; it shows almost all
the interesting paths here are being taken. (There are only a couple of
cases not being tested in compute_new_xmax_infomask, but they are
simpler ones. I will see about modifying one of the existing isolation
tests to cover those cases as well.)

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services