_USE_32BIT_TIME_T Patch

Hello,

We are getting crash while using plperl on Win32 as ActiveState perl(Win32)
uses 32-bit time_t structures. So, We have to compile DB Server's code also
with 32-bit time_t structure.

Patch is adding _USE_32BIT_TIME_T in preprocessor definitions in case
platform is Windows-32 for all project files.

Thanks & Regards,

Owais.

On Thu, Aug 30, 2012 at 6:34 AM, Owais Khan <owais(dot)khan(at)enterprisedb(dot)com> wrote:
> Hello,
>
> We are getting crash while using plperl on Win32 as ActiveState perl(Win32)
> uses 32-bit time_t structures. So, We have to compile DB Server's code also
> with 32-bit time_t structure.
>
> Patch is adding _USE_32BIT_TIME_T in preprocessor definitions in case
> platform is Windows-32 for all project files.

For additional background info, we did originally define this macro
for compatibility with third party code:

http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=22867ab9867a145b676f906b98f491c4496a70da

however it got removed here for some reason:

http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=cd004067742ee16ee63e55abfb4acbd5f09fbaab

The bottom line is, without it, pl/perl will crash with modern
versions of ActiveState Perl on Win32 (Windows users cannot use
Strawberry Perl as it doesn't contain the shared library we need).

This should definitely go in 9.2, and ideally the earlier branches
that didn't have it defined as well (this has been reported in the
past for 9.1 - for example;
http://archives.postgresql.org/pgsql-bugs/2012-04/msg00054.php) -
though I'm a little worried that adding it there may cause other
existing addons to require recompilation.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

I've added this to the release blockers section for 9.2 on the wiki,
as without it, pl/perl is unusable on Win32.

On Thu, Aug 30, 2012 at 1:39 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
> On Thu, Aug 30, 2012 at 6:34 AM, Owais Khan <owais(dot)khan(at)enterprisedb(dot)com> wrote:
>> Hello,
>>
>> We are getting crash while using plperl on Win32 as ActiveState perl(Win32)
>> uses 32-bit time_t structures. So, We have to compile DB Server's code also
>> with 32-bit time_t structure.
>>
>> Patch is adding _USE_32BIT_TIME_T in preprocessor definitions in case
>> platform is Windows-32 for all project files.
>
> For additional background info, we did originally define this macro
> for compatibility with third party code:
>
> http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=22867ab9867a145b676f906b98f491c4496a70da
>
> however it got removed here for some reason:
>
> http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=cd004067742ee16ee63e55abfb4acbd5f09fbaab
>
> The bottom line is, without it, pl/perl will crash with modern
> versions of ActiveState Perl on Win32 (Windows users cannot use
> Strawberry Perl as it doesn't contain the shared library we need).
>
> This should definitely go in 9.2, and ideally the earlier branches
> that didn't have it defined as well (this has been reported in the
> past for 9.1 - for example;
> http://archives.postgresql.org/pgsql-bugs/2012-04/msg00054.php) -
> though I'm a little worried that adding it there may cause other
> existing addons to require recompilation.
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On 08/31/2012 11:05 AM, Dave Page wrote:
> I've added this to the release blockers section for 9.2 on the wiki,
> as without it, pl/perl is unusable on Win32.

I'll have a look at it today.

cheers

andrew

On Fri, Aug 31, 2012 at 4:10 PM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>
> On 08/31/2012 11:05 AM, Dave Page wrote:
>>
>> I've added this to the release blockers section for 9.2 on the wiki,
>> as without it, pl/perl is unusable on Win32.
>
>
>
> I'll have a look at it today.

Thanks Andrew - minor clarification; unusable on MSVC/Win32. I suspect
Mingw builds may be fine, as they use a much older runtime. Of course,
we've used MSVC++ for the installer builds for years now.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On 08/31/2012 11:14 AM, Dave Page wrote:
> On Fri, Aug 31, 2012 at 4:10 PM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>> On 08/31/2012 11:05 AM, Dave Page wrote:
>>> I've added this to the release blockers section for 9.2 on the wiki,
>>> as without it, pl/perl is unusable on Win32.
>>
>>
>> I'll have a look at it today.
> Thanks Andrew - minor clarification; unusable on MSVC/Win32. I suspect
> Mingw builds may be fine, as they use a much older runtime. Of course,
> we've used MSVC++ for the installer builds for years now.

What exactly is the known combination of things that don't work, and
things that do work? My only 32 bit test environment for this (ASPerl
5.12.2 build 1202 [293621], built Sep 6, 2010, Visual C++ Express 2008,
Windows XP SP3) doesn't seem to have any problem building and running
plperl. That makes it tough to test if I don't know what exactly needs
to change to break things.

cheers

andrew

On Fri, Aug 31, 2012 at 4:57 PM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>
> On 08/31/2012 11:14 AM, Dave Page wrote:
>>
>> On Fri, Aug 31, 2012 at 4:10 PM, Andrew Dunstan <andrew(at)dunslane(dot)net>
>> wrote:
>>>
>>> On 08/31/2012 11:05 AM, Dave Page wrote:
>>>>
>>>> I've added this to the release blockers section for 9.2 on the wiki,
>>>> as without it, pl/perl is unusable on Win32.
>>>
>>>
>>>
>>> I'll have a look at it today.
>>
>> Thanks Andrew - minor clarification; unusable on MSVC/Win32. I suspect
>> Mingw builds may be fine, as they use a much older runtime. Of course,
>> we've used MSVC++ for the installer builds for years now.
>
>
>
> What exactly is the known combination of things that don't work, and things
> that do work? My only 32 bit test environment for this (ASPerl 5.12.2 build
> 1202 [293621], built Sep 6, 2010, Visual C++ Express 2008, Windows XP SP3)
> doesn't seem to have any problem building and running plperl. That makes it
> tough to test if I don't know what exactly needs to change to break things.

We're using VC++ 2010 Pro with ASPerl 5.14.2.1402 for 9.2, and VC++
2008 Pro with ASPerl 5.14.1.1401 at present. Our CM team have tried
multiple versions of Perl though, and seen the issue with 5.10 and
5.12 as well though. 5.8 seemed to be OK.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Fri, Aug 31, 2012 at 5:18 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
> On Fri, Aug 31, 2012 at 4:57 PM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>>
>> On 08/31/2012 11:14 AM, Dave Page wrote:
>>>
>>> On Fri, Aug 31, 2012 at 4:10 PM, Andrew Dunstan <andrew(at)dunslane(dot)net>
>>> wrote:
>>>>
>>>> On 08/31/2012 11:05 AM, Dave Page wrote:
>>>>>
>>>>> I've added this to the release blockers section for 9.2 on the wiki,
>>>>> as without it, pl/perl is unusable on Win32.
>>>>
>>>>
>>>>
>>>> I'll have a look at it today.
>>>
>>> Thanks Andrew - minor clarification; unusable on MSVC/Win32. I suspect
>>> Mingw builds may be fine, as they use a much older runtime. Of course,
>>> we've used MSVC++ for the installer builds for years now.
>>
>>
>>
>> What exactly is the known combination of things that don't work, and things
>> that do work? My only 32 bit test environment for this (ASPerl 5.12.2 build
>> 1202 [293621], built Sep 6, 2010, Visual C++ Express 2008, Windows XP SP3)
>> doesn't seem to have any problem building and running plperl. That makes it
>> tough to test if I don't know what exactly needs to change to break things.
>
> We're using VC++ 2010 Pro with ASPerl 5.14.2.1402 for 9.2, and VC++
> 2008 Pro with ASPerl 5.14.1.1401 at present. Our CM team have tried
> multiple versions of Perl though, and seen the issue with 5.10 and
> 5.12 as well though. 5.8 seemed to be OK.

Oh - and a further data point; we discussed the issue with one of the
senior engineers at ActiveState who confirmed that they do use
_USE_32BIT_TIME_T on Win32, and that not using it when compiling apps
that link with Perl is a known cause of crashes amongst their users.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On 08/31/2012 12:18 PM, Dave Page wrote:
> On Fri, Aug 31, 2012 at 4:57 PM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>> On 08/31/2012 11:14 AM, Dave Page wrote:
>>> On Fri, Aug 31, 2012 at 4:10 PM, Andrew Dunstan <andrew(at)dunslane(dot)net>
>>> wrote:
>>>> On 08/31/2012 11:05 AM, Dave Page wrote:
>>>>> I've added this to the release blockers section for 9.2 on the wiki,
>>>>> as without it, pl/perl is unusable on Win32.
>>>>
>>>>
>>>> I'll have a look at it today.
>>> Thanks Andrew - minor clarification; unusable on MSVC/Win32. I suspect
>>> Mingw builds may be fine, as they use a much older runtime. Of course,
>>> we've used MSVC++ for the installer builds for years now.
>>
>>
>> What exactly is the known combination of things that don't work, and things
>> that do work? My only 32 bit test environment for this (ASPerl 5.12.2 build
>> 1202 [293621], built Sep 6, 2010, Visual C++ Express 2008, Windows XP SP3)
>> doesn't seem to have any problem building and running plperl. That makes it
>> tough to test if I don't know what exactly needs to change to break things.
> We're using VC++ 2010 Pro with ASPerl 5.14.2.1402 for 9.2, and VC++
> 2008 Pro with ASPerl 5.14.1.1401 at present. Our CM team have tried
> multiple versions of Perl though, and seen the issue with 5.10 and
> 5.12 as well though. 5.8 seemed to be OK.

OK so from that I'm guessing the issue is probably VC++ 2010, which I
don't have at all, let alone on a 32-bit machine :-(

Oh, well, I'll look and see if I feel comfortable about the patch anyway.

cheers

andrew

On Fri, Aug 31, 2012 at 5:37 PM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>
> On 08/31/2012 12:18 PM, Dave Page wrote:
>>
>> On Fri, Aug 31, 2012 at 4:57 PM, Andrew Dunstan <andrew(at)dunslane(dot)net>
>> wrote:
>>>
>>> On 08/31/2012 11:14 AM, Dave Page wrote:
>>>>
>>>> On Fri, Aug 31, 2012 at 4:10 PM, Andrew Dunstan <andrew(at)dunslane(dot)net>
>>>> wrote:
>>>>>
>>>>> On 08/31/2012 11:05 AM, Dave Page wrote:
>>>>>>
>>>>>> I've added this to the release blockers section for 9.2 on the wiki,
>>>>>> as without it, pl/perl is unusable on Win32.
>>>>>
>>>>>
>>>>>
>>>>> I'll have a look at it today.
>>>>
>>>> Thanks Andrew - minor clarification; unusable on MSVC/Win32. I suspect
>>>> Mingw builds may be fine, as they use a much older runtime. Of course,
>>>> we've used MSVC++ for the installer builds for years now.
>>>
>>>
>>>
>>> What exactly is the known combination of things that don't work, and
>>> things
>>> that do work? My only 32 bit test environment for this (ASPerl 5.12.2
>>> build
>>> 1202 [293621], built Sep 6, 2010, Visual C++ Express 2008, Windows XP
>>> SP3)
>>> doesn't seem to have any problem building and running plperl. That makes
>>> it
>>> tough to test if I don't know what exactly needs to change to break
>>> things.
>>
>> We're using VC++ 2010 Pro with ASPerl 5.14.2.1402 for 9.2, and VC++
>> 2008 Pro with ASPerl 5.14.1.1401 at present. Our CM team have tried
>> multiple versions of Perl though, and seen the issue with 5.10 and
>> 5.12 as well though. 5.8 seemed to be OK.
>
>
> OK so from that I'm guessing the issue is probably VC++ 2010, which I don't
> have at all, let alone on a 32-bit machine :-(
>
> Oh, well, I'll look and see if I feel comfortable about the patch anyway.

It's only 2010 for 9.2. We're using 2008 with 9.1, which also exhibits
the problem (see the bug report linked in my first post on this
thread).

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On 08/31/2012 12:41 PM, Dave Page wrote:
> On Fri, Aug 31, 2012 at 5:37 PM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>> On 08/31/2012 12:18 PM, Dave Page wrote:
>>> On Fri, Aug 31, 2012 at 4:57 PM, Andrew Dunstan <andrew(at)dunslane(dot)net>
>>> wrote:
>>>> On 08/31/2012 11:14 AM, Dave Page wrote:
>>>>> On Fri, Aug 31, 2012 at 4:10 PM, Andrew Dunstan <andrew(at)dunslane(dot)net>
>>>>> wrote:
>>>>>> On 08/31/2012 11:05 AM, Dave Page wrote:
>>>>>>> I've added this to the release blockers section for 9.2 on the wiki,
>>>>>>> as without it, pl/perl is unusable on Win32.
>>>>>>
>>>>>>
>>>>>> I'll have a look at it today.
>>>>> Thanks Andrew - minor clarification; unusable on MSVC/Win32. I suspect
>>>>> Mingw builds may be fine, as they use a much older runtime. Of course,
>>>>> we've used MSVC++ for the installer builds for years now.
>>>>
>>>>
>>>> What exactly is the known combination of things that don't work, and
>>>> things
>>>> that do work? My only 32 bit test environment for this (ASPerl 5.12.2
>>>> build
>>>> 1202 [293621], built Sep 6, 2010, Visual C++ Express 2008, Windows XP
>>>> SP3)
>>>> doesn't seem to have any problem building and running plperl. That makes
>>>> it
>>>> tough to test if I don't know what exactly needs to change to break
>>>> things.
>>> We're using VC++ 2010 Pro with ASPerl 5.14.2.1402 for 9.2, and VC++
>>> 2008 Pro with ASPerl 5.14.1.1401 at present. Our CM team have tried
>>> multiple versions of Perl though, and seen the issue with 5.10 and
>>> 5.12 as well though. 5.8 seemed to be OK.
>>
>> OK so from that I'm guessing the issue is probably VC++ 2010, which I don't
>> have at all, let alone on a 32-bit machine :-(
>>
>> Oh, well, I'll look and see if I feel comfortable about the patch anyway.
> It's only 2010 for 9.2. We're using 2008 with 9.1, which also exhibits
> the problem (see the bug report linked in my first post on this
> thread).

Well, that makes things harder to diagnose. Why isn't my 2008 / ASPerl
5.12.2 setup exhibiting the problem?

cheers

andrew

On Fri, Aug 31, 2012 at 5:51 PM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>
> On 08/31/2012 12:41 PM, Dave Page wrote:
>>
>> On Fri, Aug 31, 2012 at 5:37 PM, Andrew Dunstan <andrew(at)dunslane(dot)net>
>> wrote:
>>>
>>> On 08/31/2012 12:18 PM, Dave Page wrote:
>>>>
>>>> On Fri, Aug 31, 2012 at 4:57 PM, Andrew Dunstan <andrew(at)dunslane(dot)net>
>>>> wrote:
>>>>>
>>>>> On 08/31/2012 11:14 AM, Dave Page wrote:
>>>>>>
>>>>>> On Fri, Aug 31, 2012 at 4:10 PM, Andrew Dunstan <andrew(at)dunslane(dot)net>
>>>>>> wrote:
>>>>>>>
>>>>>>> On 08/31/2012 11:05 AM, Dave Page wrote:
>>>>>>>>
>>>>>>>> I've added this to the release blockers section for 9.2 on the wiki,
>>>>>>>> as without it, pl/perl is unusable on Win32.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I'll have a look at it today.
>>>>>>
>>>>>> Thanks Andrew - minor clarification; unusable on MSVC/Win32. I suspect
>>>>>> Mingw builds may be fine, as they use a much older runtime. Of course,
>>>>>> we've used MSVC++ for the installer builds for years now.
>>>>>
>>>>>
>>>>>
>>>>> What exactly is the known combination of things that don't work, and
>>>>> things
>>>>> that do work? My only 32 bit test environment for this (ASPerl 5.12.2
>>>>> build
>>>>> 1202 [293621], built Sep 6, 2010, Visual C++ Express 2008, Windows XP
>>>>> SP3)
>>>>> doesn't seem to have any problem building and running plperl. That
>>>>> makes
>>>>> it
>>>>> tough to test if I don't know what exactly needs to change to break
>>>>> things.
>>>>
>>>> We're using VC++ 2010 Pro with ASPerl 5.14.2.1402 for 9.2, and VC++
>>>> 2008 Pro with ASPerl 5.14.1.1401 at present. Our CM team have tried
>>>> multiple versions of Perl though, and seen the issue with 5.10 and
>>>> 5.12 as well though. 5.8 seemed to be OK.
>>>
>>>
>>> OK so from that I'm guessing the issue is probably VC++ 2010, which I
>>> don't
>>> have at all, let alone on a 32-bit machine :-(
>>>
>>> Oh, well, I'll look and see if I feel comfortable about the patch anyway.
>>
>> It's only 2010 for 9.2. We're using 2008 with 9.1, which also exhibits
>> the problem (see the bug report linked in my first post on this
>> thread).
>
>
>
> Well, that makes things harder to diagnose. Why isn't my 2008 / ASPerl
> 5.12.2 setup exhibiting the problem?

No idea. Differences in the SDK perhaps? You're using VC++ Express
which (if memory serves) you have to download the SDK independently,
whereas we get a bundled, and possibly slightly different version with
the Pro edition.

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.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On 08/31/2012 01:10 PM, Dave Page wrote:
> On Fri, Aug 31, 2012 at 5:51 PM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>> On 08/31/2012 12:41 PM, Dave Page wrote:
>>> On Fri, Aug 31, 2012 at 5:37 PM, Andrew Dunstan <andrew(at)dunslane(dot)net>
>>> wrote:
>>>> On 08/31/2012 12:18 PM, Dave Page wrote:
>>>>> On Fri, Aug 31, 2012 at 4:57 PM, Andrew Dunstan <andrew(at)dunslane(dot)net>
>>>>> wrote:
>>>>>> On 08/31/2012 11:14 AM, Dave Page wrote:
>>>>>>> On Fri, Aug 31, 2012 at 4:10 PM, Andrew Dunstan <andrew(at)dunslane(dot)net>
>>>>>>> wrote:
>>>>>>>> On 08/31/2012 11:05 AM, Dave Page wrote:
>>>>>>>>> I've added this to the release blockers section for 9.2 on the wiki,
>>>>>>>>> as without it, pl/perl is unusable on Win32.
>>>>>>>>
>>>>>>>>
>>>>>>>> I'll have a look at it today.
>>>>>>> Thanks Andrew - minor clarification; unusable on MSVC/Win32. I suspect
>>>>>>> Mingw builds may be fine, as they use a much older runtime. Of course,
>>>>>>> we've used MSVC++ for the installer builds for years now.
>>>>>>
>>>>>>
>>>>>> What exactly is the known combination of things that don't work, and
>>>>>> things
>>>>>> that do work? My only 32 bit test environment for this (ASPerl 5.12.2
>>>>>> build
>>>>>> 1202 [293621], built Sep 6, 2010, Visual C++ Express 2008, Windows XP
>>>>>> SP3)
>>>>>> doesn't seem to have any problem building and running plperl. That
>>>>>> makes
>>>>>> it
>>>>>> tough to test if I don't know what exactly needs to change to break
>>>>>> things.
>>>>> We're using VC++ 2010 Pro with ASPerl 5.14.2.1402 for 9.2, and VC++
>>>>> 2008 Pro with ASPerl 5.14.1.1401 at present. Our CM team have tried
>>>>> multiple versions of Perl though, and seen the issue with 5.10 and
>>>>> 5.12 as well though. 5.8 seemed to be OK.
>>>>
>>>> OK so from that I'm guessing the issue is probably VC++ 2010, which I
>>>> don't
>>>> have at all, let alone on a 32-bit machine :-(
>>>>
>>>> Oh, well, I'll look and see if I feel comfortable about the patch anyway.
>>> It's only 2010 for 9.2. We're using 2008 with 9.1, which also exhibits
>>> the problem (see the bug report linked in my first post on this
>>> thread).
>>
>>
>> Well, that makes things harder to diagnose. Why isn't my 2008 / ASPerl
>> 5.12.2 setup exhibiting the problem?
> No idea. Differences in the SDK perhaps? You're using VC++ Express
> which (if memory serves) you have to download the SDK independently,
> whereas we get a bundled, and possibly slightly different version with
> the Pro edition.
>
> 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.

OK. Well, I didn't quite like the submitted patch for a couple of
reasons. First, it only affected VC2010 builds, and you said these
weren't the only ones affected. And second it didn't really highlight
what was being done.

So here are two patches, one for HEAD/9.2 and one for earlier releases,
that do this in a different way that is more obvious, and for all
versions of VC.

Please test. I will also test these.

cheers

andrew

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.

regards, tom lane

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

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> I'm not sure what we need to do to progress on this, especially re the
> back branches.

The calendar might help us here. 9.2 is due to wrap next week, but it
will likely be a couple of months before we contemplate new back-branch
releases. So we could push a fix that we don't have 100% confidence in,
knowing that there is time to recover before it will ship in any of the
proven branches. Releasing it in 9.2.0 will afford an opportunity for
more testing than we can do by ourselves.

That's not to take anything away from the fact that we ought to test as
many cases as we can now. But we do have some margin for error.

regards, tom lane

On 08/31/2012 06:39 PM, Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>> I'm not sure what we need to do to progress on this, especially re the
>> back branches.
> The calendar might help us here. 9.2 is due to wrap next week, but it
> will likely be a couple of months before we contemplate new back-branch
> releases. So we could push a fix that we don't have 100% confidence in,
> knowing that there is time to recover before it will ship in any of the
> proven branches. Releasing it in 9.2.0 will afford an opportunity for
> more testing than we can do by ourselves.
>
> That's not to take anything away from the fact that we ought to test as
> many cases as we can now. But we do have some margin for error.
>
>

OK, so I have tested it on my 32bit setup and it's working, so I'm going
to commit this for HEAD/9.2 now, so we can get that wider testing.

cheers

andrew

On Sat, Sep 1, 2012 at 1:35 AM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>
> On 08/31/2012 06:39 PM, Tom Lane wrote:
>>
>> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>>>
>>> I'm not sure what we need to do to progress on this, especially re the
>>> back branches.
>>
>> The calendar might help us here. 9.2 is due to wrap next week, but it
>> will likely be a couple of months before we contemplate new back-branch
>> releases. So we could push a fix that we don't have 100% confidence in,
>> knowing that there is time to recover before it will ship in any of the
>> proven branches. Releasing it in 9.2.0 will afford an opportunity for
>> more testing than we can do by ourselves.
>>
>> That's not to take anything away from the fact that we ought to test as
>> many cases as we can now. But we do have some margin for error.
>>
>>
>
>
>
> OK, so I have tested it on my 32bit setup and it's working, so I'm going to
> commit this for HEAD/9.2 now, so we can get that wider testing.

Thanks Andrew. Owais, can you please test on both PG and PPAS?

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company