From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Gregory Stark <stark(at)enterprisedb(dot)com> |
Cc: | "Rainer Bauer" <usenet(at)munnin(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Problem with ControlFileData structure being ABI dependent |
Date: | 2007-12-07 01:20:18 |
Message-ID: | 5579.1196990418@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Gregory Stark <stark(at)enterprisedb(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-12-07 01:44:49 | Re: "distributed checkpoint" |
Previous Message | Alvaro Herrera | 2007-12-07 00:46:22 | pgindent issue with EXEC_BACKEND-only typedefs |