Robert Haas wrote: > On Fri, Apr 1, 2011 at 5:48 PM, Bruce Momjian <br...@momjian.us> wrote: > > Alvaro Herrera wrote: > >> 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. > > > > Agreed it is not worth it but I think we should at least C comment > > something. ? I think at a minimum we should set it to > > FirstNormalTransactionId. > > I think you should leave it well enough alone. > > > I am not so concerned about this case but about other cases where we are > > computing xid distances across the invalid range. > > Such as?
This causes the freeze horizon to move backward slighly, but that is OK. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
