1
0
mirror of https://github.com/postgres/postgres.git synced 2025-06-29 10:41:53 +03:00

Replace time_t with pg_time_t (same values, but always int64) in on-disk

data structures and backend internal APIs.  This solves problems we've seen
recently with inconsistent layout of pg_control between machines that have
32-bit time_t and those that have already migrated to 64-bit time_t.  Also,
we can get out from under the problem that Windows' Unix-API emulation is not
consistent about the width of time_t.

There are a few remaining places where local time_t variables are used to hold
the current or recent result of time(NULL).  I didn't bother changing these
since they do not affect any cross-module APIs and surely all platforms will
have 64-bit time_t before overflow becomes an actual risk.  time_t should
be avoided for anything visible to extension modules, however.
This commit is contained in:
Tom Lane
2008-02-17 02:09:32 +00:00
parent ee7a6770f6
commit cd00406774
17 changed files with 98 additions and 91 deletions

View File

@ -10,7 +10,7 @@
*
*
* IDENTIFICATION
* $PostgreSQL: pgsql/src/backend/utils/adt/nabstime.c,v 1.152 2008/01/01 19:45:52 momjian Exp $
* $PostgreSQL: pgsql/src/backend/utils/adt/nabstime.c,v 1.153 2008/02/17 02:09:28 tgl Exp $
*
*-------------------------------------------------------------------------
*/
@ -86,6 +86,8 @@ static void parsetinterval(char *i_string,
* GetCurrentAbsoluteTime()
*
* Get the current system time (relative to Unix epoch).
*
* NB: this will overflow in 2038; it should be gone long before that.
*/
AbsoluteTime
GetCurrentAbsoluteTime(void)
@ -1029,12 +1031,7 @@ tintervalrel(PG_FUNCTION_ARGS)
Datum
timenow(PG_FUNCTION_ARGS)
{
time_t sec;
if (time(&sec) < 0)
PG_RETURN_ABSOLUTETIME(INVALID_ABSTIME);
PG_RETURN_ABSOLUTETIME((AbsoluteTime) sec);
PG_RETURN_ABSOLUTETIME(GetCurrentAbsoluteTime());
}
/*