> On 20 Jul 2023, at 17:24, Daniel Gustafsson <daniel@yesql.se> wrote:
>
>> On 17 Jul 2023, at 20:26, Cary Huang <cary.huang@highgo.ca> wrote:
>
>>>> Perhaps calling "tm2timestamp(&pgtm_time, 0, NULL, &ts)" without checking the return code would be just fine. I
seesome other usages of tm2timstamp() in other code areas also skip checking the return code.
>>>
>>> I think we want to know about any failures, btu we can probably make it into an
>>> elog() instead, as it should never fail.
>>
>> Yes, sure. I have corrected the error message to elog(ERROR, "timestamp out of range") on a rare tm2timestamp()
failure.
>
> I went over this again and ended up pushing it along with a catversion bump.
> Due to a mistake in my testing I didn't however catch that it was using an API
> only present in OpenSSL 1.1.1 and higher, which caused buildfailures when using
> older OpenSSL versions, so I ended up reverting it again (leaving certificate
> changes in place) to keep the buildfarm green.
>
> Will look closer at an implementation which works across all supported versions
> of OpenSSL when I have more time.
Finally had some time, and have made an updated version of the patch.
OpenSSL 1.0.2 doens't expose a function for getting the timestamp, so the patch
instead resorts to the older trick of getting the timestamp by inspecing the
diff against the UNIX epoch. When doing this, OpenSSL internally use the same
function which later in 1.1.1 was exported for getting the timestamp.
The attached version passes ssl tests for me on 1.0.2 through OpenSSL Git HEAD.
--
Daniel Gustafsson