Gregory Stark <stark@enterprisedb.com> writes:
> Oh, I bet it's not the enum which is 8 bytes but that the time_t required
> 8-byte alignment so there's 4 bytes of padding before it.
That makes more sense --- I was having a hard time imagining why anyone
would need 64-bit enums, let alone why that would silently become the
default.
>> Not sure whether an 8 byte time_t is now required by postgres. But you can get
>> the old behaviour by defining _USE_32BIT_TIME_T.
> Ugh.
> The looming problem is that you won't be able to use any libraries or
> 3rd party tools which use time_t in their interface unless you build
> with the same size time_t as they do.
AFAIK, time_t is a Unix-ism, so it's pretty unlikely to be used in the
APIs of anything on Windows.
I guess my advice would be to see if we can define _USE_32BIT_TIME_T
in port/win32.h and make it go away that way. It'd definitely be nice
if MSVC and Mingw builds weren't binary-incompatible.
In the long run we should probably fix this by getting rid of use of
time_t on-disk in favor of TimestampTz. I had partially done this in
8.3 by removing it from WAL commit records, but it's still there in
checkpoints and hence in pg_control. I think it's too late for 8.3
though (unless maybe we hit another reason for a forced initdb, which
I sure hope we don't).
regards, tom lane
