We had a puzzling situation occur last weekend. Subsequently, I figured out how
to work around it for now, but of course those who sign my checks want to know
how we can nail down forever the possibility that something like that will ever
happen again ...
The OID value for large objects crossed the 2**31 boundary, and some PHP code
stopped working (it would pull the OID value from one of our tables, then do a
lo_export call to retrieve the BLOB; however, once the value passed 2**31, it
failed because the internal library was treating the value as a signed rather
than unsigned integer).
I didn't write the PHP code, and the library is (I'm told) the PHP equivalent to
the DBI layer for Perl (which doesn't seem to have any such problem, so there
PHP freeks! 8-), so I couldn't really change that. What I did was to cast the
OID to a float, which fooled the library into treating it properly. (Thank you,
Google Groups!)
Meanwhile, we're busy counting on our fingers and toes to figure out when the
2**32 boundary will be crossed. Our best guess is that it took us around a year
to make it to the first threshold. We plan to upgrade that DB soon, which means
dump and reload, which means resetting the OID counter. So that might give us a
couple of years.
I found some indication of the problem referenced in the Pg FAQ
(http://www3.sk.postgresql.org/docs/faqs/FAQ.html):
OIDs are stored as 4-byte integers, and will overflow at 4 billion. No one has
reported this ever happening, and we plan to have the limit removed before
anyone does.
