From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Dave Page <dpage(at)pgadmin(dot)org>, Owais Khan <owais(dot)khan(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org, Hamid Quddus <hamid(dot)quddus(at)enterprisedb(dot)com> |
Subject: | Re: _USE_32BIT_TIME_T Patch |
Date: | 2012-08-31 22:12:34 |
Message-ID: | 504136D2.7090703@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 08/31/2012 03:36 PM, Tom Lane wrote:
> Dave Page <dpage(at)pgadmin(dot)org> writes:
>> As a side note - I'm not sure why _USE_32BIT_TIME_T was removed in the
>> first place; it was added specifically to avoid this sort of problem,
>> though iirc at the time we were thinking of extensions like Slony and
>> PostGIS being built with Mingw for use with the VC++ built server.
> We removed it when we changed our internal time_t usage to 64 bits:
> http://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=cd004067742ee16ee63e55abfb4acbd5f09fbaab
> Possibly that was just a brain fade caused by failing to think about
> the distinction between pg_time_t and system time_t. However, the
> code has been like that since 8.4, and nobody complained before.
> I share Andrew's unease about whether this issue is fully understood.
>
>
OTOH, the fact that we used to have it and nothing broke that we know of
is somewhat reassuring.
I'm not sure what we need to do to progress on this, especially re the
back branches.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2012-08-31 22:39:27 | Re: _USE_32BIT_TIME_T Patch |
Previous Message | Robert Haas | 2012-08-31 21:18:36 | Re: PATCH: pgbench - aggregation of info written into log |