RE: pgsql: Provide for testing on python3 modules when under MSVC

[Christian Ullrich]

* Andrew Dunstan wrote:

> On Fri, May 4, 2018 at 7:03 PM, Tom Lane  wrote:

>> Andrew Dunstan  writes:
>>> Provide for testing on python3 modules when under MSVC

>> The MSVC critters in the buildfarm seem not to like this.

> It appears that the three failing critters (whelk, thrips and
> woodlouse) are misconfigured, in that they don't have the Python
> directory in their PATH setting, so of course plpython3u won't load,

Oops. Fixed.

Thanks for pointing this out.

-- 
Christian

Re: pgsql: Provide for testing on python3 modules when under MSVC

[Andrew Dunstan]

On Fri, May 4, 2018 at 7:03 PM, Tom Lane  wrote:
> Andrew Dunstan  writes:
>> Provide for testing on python3 modules when under MSVC
>
> The MSVC critters in the buildfarm seem not to like this.
>

It appears that the three failing critters (whelk, thrips and
woodlouse) are misconfigured, in that they don't have the Python
directory in their PATH setting, so of course plpython3u won't load,
as it won't be able to locate the Python DLL. This hasn't mattered up
to now as they haven't been doing any testing, but it's exposed by our
enabling testing.

On its latest run dory, which also builds with Python3, has passed all
the python tests, so it doesn't (yet) appear that there is anything
wrong with the patch.

cheers

andrew


-- 
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: pgsql: Provide for testing on python3 modules when under MSVC

[Andrew Dunstan]

> On May 4, 2018, at 7:03 PM, Tom Lane  wrote:
> 
> Andrew Dunstan  writes:
>> Provide for testing on python3 modules when under MSVC
> 
> The MSVC critters in the buildfarm seem not to like this.
> 


Will fix in an hour or two

Cheers 

Andrew

Re: pgsql: Provide for testing on python3 modules when under MSVC

[Tom Lane]

Andrew Dunstan  writes:
> Provide for testing on python3 modules when under MSVC

The MSVC critters in the buildfarm seem not to like this.

regards, tom lane

pgsql: First-draft release notes for 10.4.

[Tom Lane]

First-draft release notes for 10.4.

As usual, the release notes for other branches will be made by cutting
these down, but put them up for community review first.

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/488ccfe40a865e3f3c6343e2de026c37ba5a7d50

Modified Files
--
doc/src/sgml/release-10.sgml | 1064 ++
1 file changed, 1064 insertions(+)

Re: pgsql: Provide for testing on python3 modules when under MSVC

[Andrew Dunstan]

On Fri, May 4, 2018 at 3:58 PM, Andrew Dunstan  wrote:
> Provide for testing on python3 modules when under MSVC
>
> This should have been done some years ago as promised in commit
> c4dcdd0c2. However, better late than never.
>
> Along the way do a little housekeeping, including using a simpler test
> for the python version being tested, and removing a redundant subroutine
> parameter. These changes only apply back to release 9.5.
>
> Backpatch to all live releases.
>


Looks like this broke. I know I tested it. I'll be back in a couple of
hours to fix it.

cheers

andrew



-- 
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

pgsql: Fix scenario where streaming standby gets stuck at a continuatio

[Heikki Linnakangas]

Fix scenario where streaming standby gets stuck at a continuation record.

If a continuation record is split so that its first half has already been
removed from the master, and is only present in pg_wal, and there is a
recycled WAL segment in the standby server that looks like it would
contain the second half, recovery would get stuck. The code in
XLogPageRead() incorrectly started streaming at the beginning of the
WAL record, even if we had already read the first page.

Backpatch to 9.4. In principle, older versions have the same problem, but
without replication slots, there was no straightforward mechanism to
prevent the master from recycling old WAL that was still needed by standby.
Without such a mechanism, I think it's reasonable to assume that there's
enough slack in how many old segments are kept around to not run into this,
or you have a WAL archive.

Reported by Jonathon Nelson. Analysis and patch by Kyotaro HORIGUCHI, with
some extra comments by me.

Discussion: 
https://www.postgresql.org/message-id/CACJqAM3xVz0JY1XFDKPP%2BJoJAjoGx%3DGNuOAshEDWCext7BFvCQ%40mail.gmail.com

Branch
--
REL9_6_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/7b7521d6577295413db2088beac6136d39d61e4e

Modified Files
--
src/backend/access/transam/xlog.c   | 44 +++--
src/backend/access/transam/xlogreader.c | 27 +++-
src/include/access/xlogreader.h |  4 +++
3 files changed, 62 insertions(+), 13 deletions(-)

pgsql: Fix scenario where streaming standby gets stuck at a continuatio

[Heikki Linnakangas]

Fix scenario where streaming standby gets stuck at a continuation record.

If a continuation record is split so that its first half has already been
removed from the master, and is only present in pg_wal, and there is a
recycled WAL segment in the standby server that looks like it would
contain the second half, recovery would get stuck. The code in
XLogPageRead() incorrectly started streaming at the beginning of the
WAL record, even if we had already read the first page.

Backpatch to 9.4. In principle, older versions have the same problem, but
without replication slots, there was no straightforward mechanism to
prevent the master from recycling old WAL that was still needed by standby.
Without such a mechanism, I think it's reasonable to assume that there's
enough slack in how many old segments are kept around to not run into this,
or you have a WAL archive.

Reported by Jonathon Nelson. Analysis and patch by Kyotaro HORIGUCHI, with
some extra comments by me.

Discussion: 
https://www.postgresql.org/message-id/CACJqAM3xVz0JY1XFDKPP%2BJoJAjoGx%3DGNuOAshEDWCext7BFvCQ%40mail.gmail.com

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/0668719801838aa6a8bda330ff9b3d20097ea844

Modified Files
--
src/backend/access/transam/xlog.c   | 44 +++--
src/backend/access/transam/xlogreader.c | 27 +++-
src/include/access/xlogreader.h |  4 +++
3 files changed, 62 insertions(+), 13 deletions(-)

pgsql: Fix scenario where streaming standby gets stuck at a continuatio

[Heikki Linnakangas]

Fix scenario where streaming standby gets stuck at a continuation record.

If a continuation record is split so that its first half has already been
removed from the master, and is only present in pg_wal, and there is a
recycled WAL segment in the standby server that looks like it would
contain the second half, recovery would get stuck. The code in
XLogPageRead() incorrectly started streaming at the beginning of the
WAL record, even if we had already read the first page.

Backpatch to 9.4. In principle, older versions have the same problem, but
without replication slots, there was no straightforward mechanism to
prevent the master from recycling old WAL that was still needed by standby.
Without such a mechanism, I think it's reasonable to assume that there's
enough slack in how many old segments are kept around to not run into this,
or you have a WAL archive.

Reported by Jonathon Nelson. Analysis and patch by Kyotaro HORIGUCHI, with
some extra comments by me.

Discussion: 
https://www.postgresql.org/message-id/CACJqAM3xVz0JY1XFDKPP%2BJoJAjoGx%3DGNuOAshEDWCext7BFvCQ%40mail.gmail.com

Branch
--
REL_10_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/ca572db22f62c24b060a0377d33ba312329b47c7

Modified Files
--
src/backend/access/transam/xlog.c   | 44 +++--
src/backend/access/transam/xlogreader.c | 27 +++-
src/include/access/xlogreader.h |  4 +++
3 files changed, 62 insertions(+), 13 deletions(-)

pgsql: Fix scenario where streaming standby gets stuck at a continuatio

[Heikki Linnakangas]

Fix scenario where streaming standby gets stuck at a continuation record.

If a continuation record is split so that its first half has already been
removed from the master, and is only present in pg_wal, and there is a
recycled WAL segment in the standby server that looks like it would
contain the second half, recovery would get stuck. The code in
XLogPageRead() incorrectly started streaming at the beginning of the
WAL record, even if we had already read the first page.

Backpatch to 9.4. In principle, older versions have the same problem, but
without replication slots, there was no straightforward mechanism to
prevent the master from recycling old WAL that was still needed by standby.
Without such a mechanism, I think it's reasonable to assume that there's
enough slack in how many old segments are kept around to not run into this,
or you have a WAL archive.

Reported by Jonathon Nelson. Analysis and patch by Kyotaro HORIGUCHI, with
some extra comments by me.

Discussion: 
https://www.postgresql.org/message-id/CACJqAM3xVz0JY1XFDKPP%2BJoJAjoGx%3DGNuOAshEDWCext7BFvCQ%40mail.gmail.com

Branch
--
REL9_4_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/c06380e97692963dd23c0a26708a431f5783c3d4

Modified Files
--
src/backend/access/transam/xlog.c   | 44 +++--
src/backend/access/transam/xlogreader.c | 27 +++-
src/include/access/xlogreader.h |  4 +++
3 files changed, 62 insertions(+), 13 deletions(-)

pgsql: Fix scenario where streaming standby gets stuck at a continuatio

[Heikki Linnakangas]

Fix scenario where streaming standby gets stuck at a continuation record.

If a continuation record is split so that its first half has already been
removed from the master, and is only present in pg_wal, and there is a
recycled WAL segment in the standby server that looks like it would
contain the second half, recovery would get stuck. The code in
XLogPageRead() incorrectly started streaming at the beginning of the
WAL record, even if we had already read the first page.

Backpatch to 9.4. In principle, older versions have the same problem, but
without replication slots, there was no straightforward mechanism to
prevent the master from recycling old WAL that was still needed by standby.
Without such a mechanism, I think it's reasonable to assume that there's
enough slack in how many old segments are kept around to not run into this,
or you have a WAL archive.

Reported by Jonathon Nelson. Analysis and patch by Kyotaro HORIGUCHI, with
some extra comments by me.

Discussion: 
https://www.postgresql.org/message-id/CACJqAM3xVz0JY1XFDKPP%2BJoJAjoGx%3DGNuOAshEDWCext7BFvCQ%40mail.gmail.com

Branch
--
REL9_5_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/4ea8f7d4553e1b90974766ab6e9a32726e80badc

Modified Files
--
src/backend/access/transam/xlog.c   | 44 +++--
src/backend/access/transam/xlogreader.c | 27 +++-
src/include/access/xlogreader.h |  4 +++
3 files changed, 62 insertions(+), 13 deletions(-)

Re: pgsql: Fix precedence problem in new Perl code.

[Mike Blackwell]

I didn't see a .perlcriticrc file in the project, so ran with our local
settings.

With those, perlcritic is pretty unhappy, even at -4, though I don't see
anything that pops out as potentially bug-inducing.  The ones I'd probably
look fixing at for starters would be the two argument form of open, and
maybe the .pl files without a #! so perlcritic doesn't mistake them for .pm
files.

It's also pretty noisy about the possible confusion cause by using a
leading zero for octal vs oct(), though that's been common practice as far
back as my memory goes.  Those could be silenced in an rc file if that's
preferred.

If there's interest I could put together a patch for some or all of this.

Mike

__
*Mike Blackwell | Technical Analyst, Distribution Services/Rollout
Management | RRD*
1750 Wallace Ave | St Charles, IL 60174-3401
Office: 630.313.7818
mike.blackw...@rrd.com
http://www.rrdonnelley.com



* *

On Fri, May 4, 2018 at 10:19 AM, Tom Lane  wrote:

> Mike Blackwell  writes:
> > In my experience, that would more commonly be written with the lower
> > precedence "or" operator (with or without the param list parens):
> >  unlink $temp_name or die "unlink: $temp_name: $!";
>
> Yeah, I thought about that, but the pre-existing rename call had ||
> and I didn't want to deviate from the existing style; I'm not a good
> enough Perl programmer to be entitled to have opinions about Perl style.
>
> Probably all of this code could use a visit from the Perl style police.
> I wonder if anyone's tried perlcritic on it recently.
>
> regards, tom lane
>

pgsql: Don't mark pages all-visible spuriously

[Alvaro Herrera]

Don't mark pages all-visible spuriously

Dan Wood diagnosed a long-standing problem that pages containing tuples
that are locked by multixacts containing live lockers may spuriously end
up as candidates for getting their all-visible flag set.  This has the
long-term effect that multixacts remain unfrozen; this may previously
pass undetected, but since commit XYZ it would be reported as
  "ERROR: found multixact 134100944 from before relminmxid 192042633"
because when a later vacuum tries to freeze the page it detects that a
multixact that should have gotten frozen, wasn't.

Dan proposed a (correct) patch that simply sets a variable to its
correct value, after a bogus initialization.  But, per discussion, it
seems better coding to avoid the bogus initializations altogether, since
they could give rise to more bugs later.  Therefore this fix rewrites
the logic a little bit to avoid depending on the bogus initializations.

This bug was part of a family introduced in 9.6 by commit a892234f830e;
later, commit 38e9f90a227d fixed most of them, but this one was
unnoticed.

Authors: Dan Wood, Pavan Deolasee, Álvaro Herrera
Reviewed-by: Masahiko Sawada, Pavan Deolasee, Álvaro Herrera
Discussion: https://postgr.es/m/84ebac55-f06d-4fbe-a3f3-8bda093ce...@amazon.com

Branch
--
REL_10_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/e1d634758e487fdec117ab4e1679240e48f2092c

Modified Files
--
src/backend/access/heap/heapam.c | 40 +---
1 file changed, 25 insertions(+), 15 deletions(-)

pgsql: Don't mark pages all-visible spuriously

[Alvaro Herrera]

Don't mark pages all-visible spuriously

Dan Wood diagnosed a long-standing problem that pages containing tuples
that are locked by multixacts containing live lockers may spuriously end
up as candidates for getting their all-visible flag set.  This has the
long-term effect that multixacts remain unfrozen; this may previously
pass undetected, but since commit XYZ it would be reported as
  "ERROR: found multixact 134100944 from before relminmxid 192042633"
because when a later vacuum tries to freeze the page it detects that a
multixact that should have gotten frozen, wasn't.

Dan proposed a (correct) patch that simply sets a variable to its
correct value, after a bogus initialization.  But, per discussion, it
seems better coding to avoid the bogus initializations altogether, since
they could give rise to more bugs later.  Therefore this fix rewrites
the logic a little bit to avoid depending on the bogus initializations.

This bug was part of a family introduced in 9.6 by commit a892234f830e;
later, commit 38e9f90a227d fixed most of them, but this one was
unnoticed.

Authors: Dan Wood, Pavan Deolasee, Álvaro Herrera
Reviewed-by: Masahiko Sawada, Pavan Deolasee, Álvaro Herrera
Discussion: https://postgr.es/m/84ebac55-f06d-4fbe-a3f3-8bda093ce...@amazon.com

Branch
--
REL9_6_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/3a11485a524ca23f404147c5736fbc2ef6b2eff2

Modified Files
--
src/backend/access/heap/heapam.c | 40 +---
1 file changed, 25 insertions(+), 15 deletions(-)

pgsql: Don't mark pages all-visible spuriously

[Alvaro Herrera]

Don't mark pages all-visible spuriously

Dan Wood diagnosed a long-standing problem that pages containing tuples
that are locked by multixacts containing live lockers may spuriously end
up as candidates for getting their all-visible flag set.  This has the
long-term effect that multixacts remain unfrozen; this may previously
pass undetected, but since commit XYZ it would be reported as
  "ERROR: found multixact 134100944 from before relminmxid 192042633"
because when a later vacuum tries to freeze the page it detects that a
multixact that should have gotten frozen, wasn't.

Dan proposed a (correct) patch that simply sets a variable to its
correct value, after a bogus initialization.  But, per discussion, it
seems better coding to avoid the bogus initializations altogether, since
they could give rise to more bugs later.  Therefore this fix rewrites
the logic a little bit to avoid depending on the bogus initializations.

This bug was part of a family introduced in 9.6 by commit a892234f830e;
later, commit 38e9f90a227d fixed most of them, but this one was
unnoticed.

Authors: Dan Wood, Pavan Deolasee, Álvaro Herrera
Reviewed-by: Masahiko Sawada, Pavan Deolasee, Álvaro Herrera
Discussion: https://postgr.es/m/84ebac55-f06d-4fbe-a3f3-8bda093ce...@amazon.com

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/d2599ecfcc74fea9fad1720a70210a740c716730

Modified Files
--
src/backend/access/heap/heapam.c | 40 +---
1 file changed, 25 insertions(+), 15 deletions(-)

pgsql: Provide for testing on python3 modules when under MSVC

[Andrew Dunstan]

Provide for testing on python3 modules when under MSVC

This should have been done some years ago as promised in commit
c4dcdd0c2. However, better late than never.

Along the way do a little housekeeping, including using a simpler test
for the python version being tested, and removing a redundant subroutine
parameter. These changes only apply back to release 9.5.

Backpatch to all live releases.

Branch
--
REL_10_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/56a45646d49b6c033adc42469f8e4361f82440a2

Modified Files
--
src/tools/msvc/Install.pm   |  6 +--
src/tools/msvc/vcregress.pl | 91 -
2 files changed, 68 insertions(+), 29 deletions(-)

pgsql: Provide for testing on python3 modules when under MSVC

[Andrew Dunstan]

Provide for testing on python3 modules when under MSVC

This should have been done some years ago as promised in commit
c4dcdd0c2. However, better late than never.

Along the way do a little housekeeping, including using a simpler test
for the python version being tested, and removing a redundant subroutine
parameter. These changes only apply back to release 9.5.

Backpatch to all live releases.

Branch
--
REL9_3_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/af39c1da7de3cad28fa2e5e08f076bff9b2d6aa7

Modified Files
--
src/tools/msvc/vcregress.pl | 54 -
1 file changed, 53 insertions(+), 1 deletion(-)

pgsql: Provide for testing on python3 modules when under MSVC

[Andrew Dunstan]

Provide for testing on python3 modules when under MSVC

This should have been done some years ago as promised in commit
c4dcdd0c2. However, better late than never.

Along the way do a little housekeeping, including using a simpler test
for the python version being tested, and removing a redundant subroutine
parameter. These changes only apply back to release 9.5.

Backpatch to all live releases.

Branch
--
REL9_4_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/134db37d21358fa5b0030c179bfa97af414d0f69

Modified Files
--
src/tools/msvc/vcregress.pl | 54 -
1 file changed, 53 insertions(+), 1 deletion(-)

pgsql: Provide for testing on python3 modules when under MSVC

[Andrew Dunstan]

Provide for testing on python3 modules when under MSVC

This should have been done some years ago as promised in commit
c4dcdd0c2. However, better late than never.

Along the way do a little housekeeping, including using a simpler test
for the python version being tested, and removing a redundant subroutine
parameter. These changes only apply back to release 9.5.

Backpatch to all live releases.

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/966268c7621c4bca534961440b497a3270395fc2

Modified Files
--
src/tools/msvc/Install.pm   |  8 +---
src/tools/msvc/vcregress.pl | 94 +++--
2 files changed, 68 insertions(+), 34 deletions(-)

pgsql: Provide for testing on python3 modules when under MSVC

[Andrew Dunstan]

Provide for testing on python3 modules when under MSVC

This should have been done some years ago as promised in commit
c4dcdd0c2. However, better late than never.

Along the way do a little housekeeping, including using a simpler test
for the python version being tested, and removing a redundant subroutine
parameter. These changes only apply back to release 9.5.

Backpatch to all live releases.

Branch
--
REL9_6_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/a9fbf550b1f1a09baa505153820d95ccd76b56b8

Modified Files
--
src/tools/msvc/Install.pm   |  6 +--
src/tools/msvc/vcregress.pl | 91 -
2 files changed, 68 insertions(+), 29 deletions(-)

pgsql: Provide for testing on python3 modules when under MSVC

[Andrew Dunstan]

Provide for testing on python3 modules when under MSVC

This should have been done some years ago as promised in commit
c4dcdd0c2. However, better late than never.

Along the way do a little housekeeping, including using a simpler test
for the python version being tested, and removing a redundant subroutine
parameter. These changes only apply back to release 9.5.

Backpatch to all live releases.

Branch
--
REL9_5_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/c1f3638d21a000ea93d4ebcf7e1f34fa92f4cc35

Modified Files
--
src/tools/msvc/Install.pm   |  6 +--
src/tools/msvc/vcregress.pl | 90 +
2 files changed, 68 insertions(+), 28 deletions(-)

pgsql: Allow MSYS as well as MINGW in Msys uname

[Andrew Dunstan]

Allow MSYS as well as MINGW in Msys uname

Msys2's uname -s outputs a string beginning MSYS rather than MINGW as is
output by Msys. Allow either in pg_upgrade's test.sh.

Backpatch to all live branches.

Branch
--
REL9_4_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/ade3b273caeefc9ec51355607679f913606eab1b

Modified Files
--
contrib/pg_upgrade/test.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

pgsql: Allow MSYS as well as MINGW in Msys uname

[Andrew Dunstan]

Allow MSYS as well as MINGW in Msys uname

Msys2's uname -s outputs a string beginning MSYS rather than MINGW as is
output by Msys. Allow either in pg_upgrade's test.sh.

Backpatch to all live branches.

Branch
--
REL_10_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/d03cf45fd97d0e6759c5862d04f8bde0a4d27575

Modified Files
--
src/bin/pg_upgrade/test.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

pgsql: Allow MSYS as well as MINGW in Msys uname

[Andrew Dunstan]

Allow MSYS as well as MINGW in Msys uname

Msys2's uname -s outputs a string beginning MSYS rather than MINGW as is
output by Msys. Allow either in pg_upgrade's test.sh.

Backpatch to all live branches.

Branch
--
REL9_3_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/594ff3d7d78c7acf73ae3ea47795dc3e07550227

Modified Files
--
contrib/pg_upgrade/test.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

pgsql: Allow MSYS as well as MINGW in Msys uname

[Andrew Dunstan]

Allow MSYS as well as MINGW in Msys uname

Msys2's uname -s outputs a string beginning MSYS rather than MINGW as is
output by Msys. Allow either in pg_upgrade's test.sh.

Backpatch to all live branches.

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/608a710195a4be20ad5f3e97b24db76aebe02808

Modified Files
--
src/bin/pg_upgrade/test.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

pgsql: Allow MSYS as well as MINGW in Msys uname

[Andrew Dunstan]

Allow MSYS as well as MINGW in Msys uname

Msys2's uname -s outputs a string beginning MSYS rather than MINGW as is
output by Msys. Allow either in pg_upgrade's test.sh.

Backpatch to all live branches.

Branch
--
REL9_6_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/679b07469a17eb08271dfeec1f015f9239ce40bd

Modified Files
--
src/bin/pg_upgrade/test.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

pgsql: Sync our copy of the timezone library with IANA release tzcode20

[Tom Lane]

Sync our copy of the timezone library with IANA release tzcode2018e.

The non-cosmetic changes involve teaching the "zic" tzdata compiler about
negative DST.  While I'm not currently intending that we start using
negative-DST data right away, it seems possible that somebody would try
to use our copy of zic with bleeding-edge IANA data.  So we'd better be
out in front of this change code-wise, even though it doesn't matter for
the data file we're shipping.

Discussion: https://postgr.es/m/30996.1525445...@sss.pgh.pa.us

Branch
--
REL9_4_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/2d123b31048d4669027bdd1741a935dfc9d8a416

Modified Files
--
src/timezone/README  |   2 +-
src/timezone/localtime.c |  14 ++---
src/timezone/strftime.c  |   2 +-
src/timezone/zic.c   | 157 ---
4 files changed, 129 insertions(+), 46 deletions(-)

pgsql: Sync our copy of the timezone library with IANA release tzcode20

[Tom Lane]

Sync our copy of the timezone library with IANA release tzcode2018e.

The non-cosmetic changes involve teaching the "zic" tzdata compiler about
negative DST.  While I'm not currently intending that we start using
negative-DST data right away, it seems possible that somebody would try
to use our copy of zic with bleeding-edge IANA data.  So we'd better be
out in front of this change code-wise, even though it doesn't matter for
the data file we're shipping.

Discussion: https://postgr.es/m/30996.1525445...@sss.pgh.pa.us

Branch
--
REL9_6_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/7a83323f2daaa0aa73e60b82ba48f651c6934bc5

Modified Files
--
src/timezone/README  |   2 +-
src/timezone/localtime.c |  14 ++---
src/timezone/strftime.c  |   2 +-
src/timezone/zic.c   | 157 ---
4 files changed, 129 insertions(+), 46 deletions(-)

pgsql: Sync our copy of the timezone library with IANA release tzcode20

[Tom Lane]

Sync our copy of the timezone library with IANA release tzcode2018e.

The non-cosmetic changes involve teaching the "zic" tzdata compiler about
negative DST.  While I'm not currently intending that we start using
negative-DST data right away, it seems possible that somebody would try
to use our copy of zic with bleeding-edge IANA data.  So we'd better be
out in front of this change code-wise, even though it doesn't matter for
the data file we're shipping.

Discussion: https://postgr.es/m/30996.1525445...@sss.pgh.pa.us

Branch
--
REL9_5_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/4e0e9e59b7cef3bb9518e12ba44f04d91224779f

Modified Files
--
src/timezone/README  |   2 +-
src/timezone/localtime.c |  14 ++---
src/timezone/strftime.c  |   2 +-
src/timezone/zic.c   | 157 ---
4 files changed, 129 insertions(+), 46 deletions(-)

pgsql: Sync our copy of the timezone library with IANA release tzcode20

[Tom Lane]

Sync our copy of the timezone library with IANA release tzcode2018e.

The non-cosmetic changes involve teaching the "zic" tzdata compiler about
negative DST.  While I'm not currently intending that we start using
negative-DST data right away, it seems possible that somebody would try
to use our copy of zic with bleeding-edge IANA data.  So we'd better be
out in front of this change code-wise, even though it doesn't matter for
the data file we're shipping.

Discussion: https://postgr.es/m/30996.1525445...@sss.pgh.pa.us

Branch
--
REL_10_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/b49f4e69a9bb54c743ea2101bee79d06aa438772

Modified Files
--
src/timezone/README  |   2 +-
src/timezone/localtime.c |  14 ++---
src/timezone/strftime.c  |   2 +-
src/timezone/zic.c   | 157 ---
4 files changed, 129 insertions(+), 46 deletions(-)

Re: pgsql: Fix precedence problem in new Perl code.

[Tom Lane]

Mike Blackwell  writes:
> In my experience, that would more commonly be written with the lower
> precedence "or" operator (with or without the param list parens):
>  unlink $temp_name or die "unlink: $temp_name: $!";

Yeah, I thought about that, but the pre-existing rename call had ||
and I didn't want to deviate from the existing style; I'm not a good
enough Perl programmer to be entitled to have opinions about Perl style.

Probably all of this code could use a visit from the Perl style police.
I wonder if anyone's tried perlcritic on it recently.

regards, tom lane

Re: pgsql: Fix precedence problem in new Perl code.

[Mike Blackwell]

In my experience, that would more commonly be written with the lower
precedence "or" operator (with or without the param list parens):

 unlink $temp_name or die "unlink: $temp_name: $!";

__
*Mike Blackwell | Technical Analyst, Distribution Services/Rollout
Management | RRD*
1750 Wallace Ave | St Charles, IL 60174-3401
Office: 630.313.7818
mike.blackw...@rrd.com
http://www.rrdonnelley.com



* *

On Fri, May 4, 2018 at 8:46 AM, Tom Lane  wrote:

> Fix precedence problem in new Perl code.
>
> I think this bit of commit 1f1cd9b5d didn't do quite what I meant :-(
>
> Branch
> --
> master
>
> Details
> ---
> https://git.postgresql.org/pg/commitdiff/59cb323053f4ed582d4e71acaeb577
> 0603f074db
>
> Modified Files
> --
> src/backend/catalog/Catalog.pm | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>

pgsql: Fix precedence problem in new Perl code.

[Tom Lane]

Fix precedence problem in new Perl code.

I think this bit of commit 1f1cd9b5d didn't do quite what I meant :-(

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/59cb323053f4ed582d4e71acaeb5770603f074db

Modified Files
--
src/backend/catalog/Catalog.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

pgsql: pg_dump: Use current_database() instead of PQdb()

[Peter Eisentraut]

pg_dump: Use current_database() instead of PQdb()

For querying pg_database about information about the database being
dumped, look up by using current_database() instead of the value
obtained from PQdb().  When using a connection proxy, the value from
PQdb() might not be the real name of the database.

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/1cd2445c9985719ea1bb9f644373481c8702af64

Modified Files
--
src/bin/pg_dump/pg_dump.c | 52 ---
1 file changed, 22 insertions(+), 30 deletions(-)

pgsql: Don't truncate away non-key attributes for leftmost downlinks.

[Teodor Sigaev]

Don't truncate away non-key attributes for leftmost downlinks.

nbtsort.c does not need to truncate away non-key attributes for the
minimum key of the leftmost page on a level, since this is only used to
build a minus infinity downlink for the level's leftmost page.
Truncating away non-key attributes in advance of truncating away all
attributes in _bt_sortaddtup() does not affect the correctness of CREATE
INDEX, but it is misleading.

Author: Peter Geoghegan
Discussion: 
https://www.postgresql.org/message-id/CAH2-WzkAS2M3ussHG-s_Av=zo6dpjoxyu5fnrkynxqv+yzg...@mail.gmail.com

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/2a9e04f0a8ada12d4af4f095e4dbe164e2983bce

Modified Files
--
src/backend/access/nbtree/nbtsort.c | 30 ++
1 file changed, 14 insertions(+), 16 deletions(-)

pgsql: Re-think predicate locking on GIN indexes.

[Teodor Sigaev]

Re-think predicate locking on GIN indexes.

The principle behind the locking was not very well thought-out, and not
documented. Add a section in the README to explain how it's supposed to
work, and change the code so that it actually works that way.

This fixes two bugs:

1. If fast update was turned on concurrently, subsequent inserts to the
   pending list would not conflict with predicate locks that were acquired
   earlier, on entry pages. The included 'predicate-gin-fastupdate' test
   demonstrates that. To fix, make all scans acquire a predicate lock on
   the metapage. That lock represents a scan of the pending list, whether
   or not there is a pending list at the moment. Forget about the
   optimization to skip locking/checking for locks, when fastupdate=off.
2. If a scan finds no match, it still needs to lock the entry page. The
   point of predicate locks is to lock the gabs between values, whether
   or not there is a match. The included 'predicate-gin-nomatch' test
   tests that case.

In addition to those two bug fixes, this removes some unnecessary locking,
following the principle laid out in the README. Because all items in
a posting tree have the same key value, a lock on the posting tree root is
enough to cover all the items. (With a very large posting tree, it would
possibly be better to lock the posting tree leaf pages instead, so that a
"skip scan" with a query like "A & B", you could avoid unnecessary conflict
if a new tuple is inserted with A but !B. But let's keep this simple.)

Also, some spelling  fixes.

Author: Heikki Linnakangas with some editorization by me
Review: Andrey Borodin, Alexander Korotkov
Discussion: 
https://www.postgresql.org/message-id/0b3ad2c2-2692-62a9-3a04-5724f2af9...@iki.fi

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/0bef1c0678d94436f80450d562a866bb6fa5e509

Modified Files
--
src/backend/access/gin/README  |  34 ++
src/backend/access/gin/ginbtree.c  |   3 +
src/backend/access/gin/gindatapage.c   |   7 +-
src/backend/access/gin/ginfast.c   |   8 ++
src/backend/access/gin/ginget.c| 116 ++---
src/backend/access/gin/gininsert.c |  26 +
src/backend/access/gin/ginutil.c   |   7 --
src/backend/access/gin/ginvacuum.c |   1 -
src/backend/access/gist/gist.c |   2 +-
src/backend/storage/lmgr/README-SSI|  22 ++--
src/include/access/gin_private.h   |   3 -
.../expected/predicate-gin-fastupdate.out  |  30 ++
.../isolation/expected/predicate-gin-nomatch.out   |  15 +++
src/test/isolation/expected/predicate-gin.out  |   4 +-
src/test/isolation/isolation_schedule  |   2 +
.../isolation/specs/predicate-gin-fastupdate.spec  |  49 +
.../isolation/specs/predicate-gin-nomatch.spec |  35 +++
src/test/isolation/specs/predicate-gin.spec|   4 +-
18 files changed, 251 insertions(+), 117 deletions(-)