We've had some recent bad experiences with trying to interpret pg_control on a machine where time_t is a different width from the system that made the file, eg here http://archives.postgresql.org/pgsql-admin/2008-01/msg00023.php and I think there was another similar case recently. Since the whole world is going to be gradually converting to 64-bit time_t, this problem is clearly going to get worse before it gets better. So we need to replace the time_t fields in pg_control and WAL records with something less platform-dependent.
There are two reasonable choices to change them to: TimestampTz or pg_time_t. I see the following pros and cons: TimestampTz: fractional-second resolution, but since it might be either float or int, there'd still be a problem of not being able to print it correctly on a machine with a different integer-timestamp setting. On the plus side, the field width is the same both ways, so the field-shifting problems noted above wouldn't exist. In principle we could know by looking at the integer-timestamp field of pg_control how to interpret the timestamp fields. pg_time_t: only one-second resolution. Also, since this is typedef'd as int64, the field-width problem comes right back to haunt us on machines where INT64_IS_BROKEN. On the other hand, it's not clear that there are any such machines anymore, and furthermore such a machine is going to have a different idea of the width of some other pg_control fields such as system_identifier anyway. On reflection I'm leaning to pg_time_t; its portability issues seem less bad and I don't see huge value in recording checkpoint or startup/shutdown times to sub-second resolution. But I wonder if anyone wants to argue for the other choice? BTW, I think we should also get rid of time_t in favor of pg_time_t (or possibly TimestampTz) in all internal APIs, so that we can get rid of the current Windows build restriction about _USE_32BIT_TIME_T. If we don't expose time_t anywhere then it won't matter which way extensions are built. There are various modules that use time_t internally to store current or recent values of time(NULL), and it's probably all right to leave those as-is as long as the value is not exposed outside the module. But maybe we should convert them to pg_time_t too, just to have a uniform coding rule "don't use time_t". Thoughts? regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster