Re: BlockNumber fixes

Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > I did some research on this and generated the following patch.  I didn't
> > find much in the way of problems except two vacuum.c fields that should
> > probably be BlockNumber.  freespace.c also has a numPages field in
> > FSMRelation that is int.  Should that be BlockNumber?
> 
> Not necessary, since the freespace map will never be large enough to
> overflow a signed int (it wouldn't fit in the address space if it were).
> I think that your changes in vacuum.c are probably unnecessary for the
> same reason.  I am generally wary of changing values from signed to
> unsigned without close analysis of how they are used --- did you look
> at *every* comparison involving these fields?  How about arithmetic
> that might compute a negative result?

The only computation I saw was:
 vacuumed_pages = vacuum_pages->num_pages - vacuum_pages->empty_end_pages;

vacuumed_pages is signed, the others are unsigned.  However, we print
these values as %u so there is a certain confusion there.

If you say it isn't a problem here, I will just mark the item as done
and that we are handling the block numbers correctly.  The only other
unusual case I saw was tid outputing block number as %d and not %u.  Is
that OK?
   sprintf(buf, "(%d,%d)", (int) blockNumber, (int) offsetNumber);

tidin uses atoi:
   blockNumber = (BlockNumber) atoi(coord[0]);

so at least it is consistent.  ;-)  Doesn't seem right, however.

Also, pg_class.relpages is an int.  We don't have unsigned int columns.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026