On 8 May 2017 at 02:57, Tom Lane wrote:
> David Rowley writes:
>> OK, so it looks like GenerateTimezoneFiles in Install.pm for the MSVC
>> build does not quite do what make install does for src/timezone.
>> Nothing seems to pass the -p parameter as the following is doing:
>
> Ah-hah. Still, the
Release notes for 9.6.3, 9.5.7, 9.4.12, 9.3.17, 9.2.21.
Branch
--
REL9_4_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/a6b6bb64094cdf40488bc1ac64bc2c294e7383b5
Modified Files
--
doc/src/sgml/release-9.2.sgml | 325 +++
doc/src/sgml/rel
Release notes for 9.6.3, 9.5.7, 9.4.12, 9.3.17, 9.2.21.
Branch
--
REL9_3_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/e2dd4337403edf9b2d69d598ea373b6de969b186
Modified Files
--
doc/src/sgml/release-9.2.sgml | 325 +++
doc/src/
Release notes for 9.6.3, 9.5.7, 9.4.12, 9.3.17, 9.2.21.
Branch
--
REL9_5_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/04b4183666409c538cf900a486028ac3fb883b8b
Modified Files
--
doc/src/sgml/release-9.2.sgml | 325 +++
doc/src/sgml/release
Release notes for 9.6.3, 9.5.7, 9.4.12, 9.3.17, 9.2.21.
Branch
--
REL9_6_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/3178f467c81823954f76603a03ad3edb7f54f588
Modified Files
--
doc/src/sgml/release-9.2.sgml | 325 +++
doc/src/sgml/release-9.3.sgml |
Release notes for 9.6.3, 9.5.7, 9.4.12, 9.3.17, 9.2.21.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/27dae036a5809a61104b7380f0cd98c37b43170f
Modified Files
--
doc/src/sgml/release-9.2.sgml | 325 +++
doc/src/sgml/release-9.3.sg
Release notes for 9.6.3, 9.5.7, 9.4.12, 9.3.17, 9.2.21.
Branch
--
REL9_2_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/f79531ffd42f2d0e5c35d1dffbc2c2f2cd2086dc
Modified Files
--
doc/src/sgml/release-9.2.sgml | 325 ++
1 fil
Third pass on 9.6.3 release notes.
Add updates for recent commits.
In passing, credit Etsuro Fujita for his work on the postgres_fdw
query cancel feature in 9.6; I seem to have missed that in the
original drafting of the 9.6 notes.
Branch
--
master
Details
---
https://git.postgresql.org
I wrote:
> I concur with your thought that these are separate bugs and deserve
> separate commits. Will do that in a minute.
BTW, I wrote in the commit log message that the posixrules omission
had only minimal consequences, but on closer look that's wrong:
the hardwired default in the timezone co
Fix memory leaks if random salt generation fails.
In the backend, this is just to silence coverity warnings, but in the
frontend, it's a genuine leak, even if extremely rare.
Spotted by Coverity, patch by Michael Paquier.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commit
Guard against null t->tm_zone in strftime.c.
The upstream IANA code does not guard against null TM_ZONE pointers in this
function, but in our code there is such a check in the other pre-existing
use of t->tm_zone. We do have some places that set pg_tm.tm_zone to NULL.
I'm not entirely sure it's p
Guard against null t->tm_zone in strftime.c.
The upstream IANA code does not guard against null TM_ZONE pointers in this
function, but in our code there is such a check in the other pre-existing
use of t->tm_zone. We do have some places that set pg_tm.tm_zone to NULL.
I'm not entirely sure it's p
Guard against null t->tm_zone in strftime.c.
The upstream IANA code does not guard against null TM_ZONE pointers in this
function, but in our code there is such a check in the other pre-existing
use of t->tm_zone. We do have some places that set pg_tm.tm_zone to NULL.
I'm not entirely sure it's p
Guard against null t->tm_zone in strftime.c.
The upstream IANA code does not guard against null TM_ZONE pointers in this
function, but in our code there is such a check in the other pre-existing
use of t->tm_zone. We do have some places that set pg_tm.tm_zone to NULL.
I'm not entirely sure it's p
Guard against null t->tm_zone in strftime.c.
The upstream IANA code does not guard against null TM_ZONE pointers in this
function, but in our code there is such a check in the other pre-existing
use of t->tm_zone. We do have some places that set pg_tm.tm_zone to NULL.
I'm not entirely sure it's p
Guard against null t->tm_zone in strftime.c.
The upstream IANA code does not guard against null TM_ZONE pointers in this
function, but in our code there is such a check in the other pre-existing
use of t->tm_zone. We do have some places that set pg_tm.tm_zone to NULL.
I'm not entirely sure it's p
Install the "posixrules" timezone link in MSVC builds.
Somehow, we'd missed ever doing this. The consequences aren't too
severe: basically, the timezone library would fall back on its hardwired
notion of the DST transition dates to use for a POSIX-style zone name,
rather than obeying US/Eastern w
Install the "posixrules" timezone link in MSVC builds.
Somehow, we'd missed ever doing this. The consequences aren't too
severe: basically, the timezone library would fall back on its hardwired
notion of the DST transition dates to use for a POSIX-style zone name,
rather than obeying US/Eastern w
Install the "posixrules" timezone link in MSVC builds.
Somehow, we'd missed ever doing this. The consequences aren't too
severe: basically, the timezone library would fall back on its hardwired
notion of the DST transition dates to use for a POSIX-style zone name,
rather than obeying US/Eastern w
Install the "posixrules" timezone link in MSVC builds.
Somehow, we'd missed ever doing this. The consequences aren't too
severe: basically, the timezone library would fall back on its hardwired
notion of the DST transition dates to use for a POSIX-style zone name,
rather than obeying US/Eastern w
Install the "posixrules" timezone link in MSVC builds.
Somehow, we'd missed ever doing this. The consequences aren't too
severe: basically, the timezone library would fall back on its hardwired
notion of the DST transition dates to use for a POSIX-style zone name,
rather than obeying US/Eastern w
Install the "posixrules" timezone link in MSVC builds.
Somehow, we'd missed ever doing this. The consequences aren't too
severe: basically, the timezone library would fall back on its hardwired
notion of the DST transition dates to use for a POSIX-style zone name,
rather than obeying US/Eastern w
Restore fullname[] contents before falling through in pg_open_tzfile().
Fix oversight in commit af2c5aa88: if the shortcut open() doesn't work,
we need to reset fullname[] to be just the name of the toplevel tzdata
directory before we fall through into the pre-existing code. This failed
to be exp
Restore fullname[] contents before falling through in pg_open_tzfile().
Fix oversight in commit af2c5aa88: if the shortcut open() doesn't work,
we need to reset fullname[] to be just the name of the toplevel tzdata
directory before we fall through into the pre-existing code. This failed
to be exp
Restore fullname[] contents before falling through in pg_open_tzfile().
Fix oversight in commit af2c5aa88: if the shortcut open() doesn't work,
we need to reset fullname[] to be just the name of the toplevel tzdata
directory before we fall through into the pre-existing code. This failed
to be exp
Restore fullname[] contents before falling through in pg_open_tzfile().
Fix oversight in commit af2c5aa88: if the shortcut open() doesn't work,
we need to reset fullname[] to be just the name of the toplevel tzdata
directory before we fall through into the pre-existing code. This failed
to be exp
Restore fullname[] contents before falling through in pg_open_tzfile().
Fix oversight in commit af2c5aa88: if the shortcut open() doesn't work,
we need to reset fullname[] to be just the name of the toplevel tzdata
directory before we fall through into the pre-existing code. This failed
to be exp
Restore fullname[] contents before falling through in pg_open_tzfile().
Fix oversight in commit af2c5aa88: if the shortcut open() doesn't work,
we need to reset fullname[] to be just the name of the toplevel tzdata
directory before we fall through into the pre-existing code. This failed
to be exp
Amit Kapila writes:
> On Sun, May 7, 2017 at 8:27 PM, Tom Lane wrote:
>> Ah-hah. Still, the log message should have been there before.
> No, it didn't exist before because dirname passed to scan_directory_ci
> didn't contain the filename appended to it.
Gotcha. On closer look, the "fall throu
On Sun, May 7, 2017 at 8:27 PM, Tom Lane wrote:
> David Rowley writes:
>> OK, so it looks like GenerateTimezoneFiles in Install.pm for the MSVC
>> build does not quite do what make install does for src/timezone.
>> Nothing seems to pass the -p parameter as the following is doing:
>
> Ah-hah. Sti
On Sun, May 7, 2017 at 2:33 PM, David Rowley
wrote:
> , On 7 May 2017 at 17:19, Tom Lane wrote:
>> Amit Kapila writes:
>>> On Wed, May 3, 2017 at 7:21 AM, Tom Lane wrote:
Improve performance of timezone loading, especially pg_timezone_names view.
>>
>>> I am consistently getting below erro
David Rowley writes:
> OK, so it looks like GenerateTimezoneFiles in Install.pm for the MSVC
> build does not quite do what make install does for src/timezone.
> Nothing seems to pass the -p parameter as the following is doing:
Ah-hah. Still, the log message should have been there before.
Maybe
On 7 May 2017 at 21:33, David Rowley wrote:
> I've attached a patch for review. My perl skills are at "trial and
> error" level, so please review carefully.
Actually, my Perl code contained a superfluous line to trim the
whitespace from $posixrules.
The attached is a version without it, which st
On 7 May 2017 at 21:03, David Rowley wrote:
> Perhaps we just need to put the NUL char back, to trim off the filename again:
>
> /* If that didn't work, fall through to do it the hard way */
> fullname[fullnamelen] = '\0';
>
> but I've not yet looked into why the file is missing in the first place
, On 7 May 2017 at 17:19, Tom Lane wrote:
> Amit Kapila writes:
>> On Wed, May 3, 2017 at 7:21 AM, Tom Lane wrote:
>>> Improve performance of timezone loading, especially pg_timezone_names view.
>
>> I am consistently getting below error after this commit in my Win7 machine:
>> running bootstrap
35 matches
Mail list logo
