Koichi Suzuki <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend