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

* 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

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

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

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

> 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

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.

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

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

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,

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

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

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

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

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

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

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

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

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

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

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

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,

pgsql: Don't mark pages all-visible spuriously

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

pgsql: Don't mark pages all-visible spuriously

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

pgsql: Don't mark pages all-visible spuriously

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

pgsql: Provide for testing on python3 modules when under MSVC

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

pgsql: Provide for testing on python3 modules when under MSVC

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

pgsql: Provide for testing on python3 modules when under MSVC

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

pgsql: Provide for testing on python3 modules when under MSVC

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

pgsql: Provide for testing on python3 modules when under MSVC

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

pgsql: Provide for testing on python3 modules when under MSVC

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

pgsql: Allow MSYS as well as MINGW in Msys uname

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 ---

pgsql: Allow MSYS as well as MINGW in Msys uname

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 ---

pgsql: Allow MSYS as well as MINGW in Msys uname

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 ---

pgsql: Allow MSYS as well as MINGW in Msys uname

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 ---

pgsql: Allow MSYS as well as MINGW in Msys uname

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 ---

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

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

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

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

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

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

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

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

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

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

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

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 |

pgsql: Fix precedence problem in new Perl code.

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

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

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

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

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

pgsql: Re-think predicate locking on GIN indexes.

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