Koichi Suzuki <koichi@intellilink.co.jp> writes:
> Here're a couple of patches for PostgreSQL 64bit support. There're just
> two extension to 64bit, size of shared memory and transaction ID.
I've applied the part of this that seemed reasonably noncontroversial,
namely the fixes to do shared memory size calculation in size_t
arithmetic instead of int arithmetic. (While at it, I extended the Size
convention to all the shared memory sizing routines, not just buffers,
and added code to detect overflows in the calculations. That way we
don't need a "64 bit" configure switch.) While I still remain
unconvinced that there's any real-world need for more than 2Gb of
shared_buffers, this change certainly makes the code more robust against
configuration errors, and it has essentially zero cost (except maybe a
few more milliseconds during postmaster start).
On the other hand, I think the 64-bit XID idea needs considerably more
work before being proposed again. That would incur serious costs due
to the expansion of tuple headers, and there's no evidence that the
distributed cost would be bought back by avoiding one vacuum pass every
billion transactions. (Your description of the patch claimed that
vacuuming requires shutting down the database, which is simply wrong.)
Also, as previously noted, you can't just whack the size of XID around
without considering side-effects on CID, OID, Datum, etc.
regards, tom lane