Excerpts from Bruce Momjian's message of vie abr 01 16:50:29 -0300 2011:
> To do the right thing every computation that passes over the xid
> wraparound bounary should subtract FirstNormalTransactionId, not just
> those that fall in the boundry. That would prevent the value from going
> backward and still allow the mapping you liked; it isn't worth it, but
> that is the right answer.
This code is only concerned calculating an immediate the wrap horizon
for the autovacuuming run that's about to take place. If it's wrong in
one or three counts doesn't mean much. Consider what would happen if
load was high and it would have taken 100 extra milliseconds to get to
that bit: ReadNewTransactionId would have returned a value 3
transactions later. Furthermore, before this value is even used at all
for vacuuming, there has to be a whole lot of inter-process signalling,
a fork, and a new backend startup.
I think this should be left alone. As you said, it isn't worth it.
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support