[COMMITTERS] pgsql: Add basic pg_dumpall/pg_restore TAP tests

[Stephen Frost]

Add basic pg_dumpall/pg_restore TAP tests

For reasons unknown, pg_dumpall and pg_restore managed to escape the
basic set of TAP tests that were added for pg_dump in 6bd356c3, so
let's get them added now.  A few minor adjustments are also made to the
dump/restore tests to improve code coverage for pg_restore/pg_dumpall.

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/9b815a8ff227e62442259e0fbabc5cf37e433df9

Modified Files
--
src/bin/pg_dump/t/001_basic.pl   | 61 +++-
src/bin/pg_dump/t/002_pg_dump.pl |  8 +++---
2 files changed, 64 insertions(+), 5 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] pgsql: Merge two copies of tuple-building code in pltcl.c.

[Tom Lane]

Merge two copies of tuple-building code in pltcl.c.

Make pltcl_trigger_handler() construct modified tuples using
pltcl_build_tuple_result(), rather than its own copy of essentially
the same logic.  This results in slightly different message wording for
the error cases, and in one case a different SQLSTATE, but it seems
unlikely that any existing applications are depending on any of those
details.

While at it, fix a typo in commit 26abb50c4: pltcl_build_tuple_result was
applying encoding conversion in the wrong direction.  That would be a
back-patchable bug fix, except the code hasn't shipped yet.

Jim Nasby, reviewed by me

Discussion: 
https://postgr.es/m/d2c6425a-d9e0-f034-f774-4a872c234...@bluetreble.com

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/de5fed0d0c704e3d1a928bf420663319d898cee4

Modified Files
--
src/pl/tcl/pltcl.c | 113 ++---
1 file changed, 39 insertions(+), 74 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] pgsql: Protect against NULL-dereference in pg_dump

[Stephen Frost]

Protect against NULL-dereference in pg_dump

findTableByOid() is allowed to return NULL and we should therefore be
checking for that case.  getOwnedSeqs() and dumpSequence() shouldn't
ever actually see this happen, but given odd circumstances it might and
commit f9e439b1 probably shouldn't have removed that check.

Pointed out by Coverity.  Initial patch from Michael Paquier.

Back-patch to 9.6, where that commit had removed the check.

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/d74ecbc8d85eb7a2aa1d5516c5c38d6ab0cbbd82

Modified Files
--
src/bin/pg_dump/pg_dump.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] pgsql: Protect against NULL-dereference in pg_dump

[Stephen Frost]

Protect against NULL-dereference in pg_dump

findTableByOid() is allowed to return NULL and we should therefore be
checking for that case.  getOwnedSeqs() and dumpSequence() shouldn't
ever actually see this happen, but given odd circumstances it might and
commit f9e439b1 probably shouldn't have removed that check.

Pointed out by Coverity.  Initial patch from Michael Paquier.

Back-patch to 9.6, where that commit had removed the check.

Branch
--
REL9_6_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/8b1bf3161b360003182997b4e258b8fac78c3bdf

Modified Files
--
src/bin/pg_dump/pg_dump.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] pgsql: Invalidate cached plans on FDW option changes.

[Tom Lane]

Invalidate cached plans on FDW option changes.

This fixes problems where a plan must change but fails to do so,
as seen in a bug report from Rajkumar Raghuwanshi.

For ALTER FOREIGN TABLE OPTIONS, do this through the standard method of
forcing a relcache flush on the table.  For ALTER FOREIGN DATA WRAPPER
and ALTER SERVER, just flush the whole plan cache on any change in
pg_foreign_data_wrapper or pg_foreign_server.  That matches the way
we handle some other low-probability cases such as opclass changes, and
it's unclear that the case arises often enough to be worth working harder.
Besides, that gives a patch that is simple enough to back-patch with
confidence.

Back-patch to 9.3.  In principle we could apply the code change to 9.2 as
well, but (a) we lack postgres_fdw to test it with, (b) it's doubtful that
anyone is doing anything exciting enough with FDWs that far back to need
this desperately, and (c) the patch doesn't apply cleanly.

Patch originally by Amit Langote, reviewed by Etsuro Fujita and Ashutosh
Bapat, who each contributed substantial changes as well.

Discussion: 
https://postgr.es/m/CAKcux6m5cA6rRPTKkqVdJ-R=KKDfe35Q_ZuUqxDSV_4hwga=o...@mail.gmail.com

Branch
--
REL9_3_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/a8191800a6e63e8f4a61e6c3eccdfb428eb085d8

Modified Files
--
contrib/postgres_fdw/expected/postgres_fdw.out | 57 ++
contrib/postgres_fdw/sql/postgres_fdw.sql  | 15 +++
src/backend/commands/tablecmds.c   |  6 +++
src/backend/utils/cache/plancache.c|  2 +
4 files changed, 80 insertions(+)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] pgsql: Invalidate cached plans on FDW option changes.

[Tom Lane]

Invalidate cached plans on FDW option changes.

This fixes problems where a plan must change but fails to do so,
as seen in a bug report from Rajkumar Raghuwanshi.

For ALTER FOREIGN TABLE OPTIONS, do this through the standard method of
forcing a relcache flush on the table.  For ALTER FOREIGN DATA WRAPPER
and ALTER SERVER, just flush the whole plan cache on any change in
pg_foreign_data_wrapper or pg_foreign_server.  That matches the way
we handle some other low-probability cases such as opclass changes, and
it's unclear that the case arises often enough to be worth working harder.
Besides, that gives a patch that is simple enough to back-patch with
confidence.

Back-patch to 9.3.  In principle we could apply the code change to 9.2 as
well, but (a) we lack postgres_fdw to test it with, (b) it's doubtful that
anyone is doing anything exciting enough with FDWs that far back to need
this desperately, and (c) the patch doesn't apply cleanly.

Patch originally by Amit Langote, reviewed by Etsuro Fujita and Ashutosh
Bapat, who each contributed substantial changes as well.

Discussion: 
https://postgr.es/m/CAKcux6m5cA6rRPTKkqVdJ-R=KKDfe35Q_ZuUqxDSV_4hwga=o...@mail.gmail.com

Branch
--
REL9_5_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/aaf12e577ee9bfe71aae43879e41007628ad1143

Modified Files
--
contrib/postgres_fdw/expected/postgres_fdw.out | 57 ++
contrib/postgres_fdw/sql/postgres_fdw.sql  | 15 +++
src/backend/commands/tablecmds.c   |  6 +++
src/backend/utils/cache/plancache.c|  2 +
4 files changed, 80 insertions(+)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] pgsql: Invalidate cached plans on FDW option changes.

[Tom Lane]

Invalidate cached plans on FDW option changes.

This fixes problems where a plan must change but fails to do so,
as seen in a bug report from Rajkumar Raghuwanshi.

For ALTER FOREIGN TABLE OPTIONS, do this through the standard method of
forcing a relcache flush on the table.  For ALTER FOREIGN DATA WRAPPER
and ALTER SERVER, just flush the whole plan cache on any change in
pg_foreign_data_wrapper or pg_foreign_server.  That matches the way
we handle some other low-probability cases such as opclass changes, and
it's unclear that the case arises often enough to be worth working harder.
Besides, that gives a patch that is simple enough to back-patch with
confidence.

Back-patch to 9.3.  In principle we could apply the code change to 9.2 as
well, but (a) we lack postgres_fdw to test it with, (b) it's doubtful that
anyone is doing anything exciting enough with FDWs that far back to need
this desperately, and (c) the patch doesn't apply cleanly.

Patch originally by Amit Langote, reviewed by Etsuro Fujita and Ashutosh
Bapat, who each contributed substantial changes as well.

Discussion: 
https://postgr.es/m/CAKcux6m5cA6rRPTKkqVdJ-R=KKDfe35Q_ZuUqxDSV_4hwga=o...@mail.gmail.com

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/c52d37c8b3674f1ca9ead297480ade0ac9c54174

Modified Files
--
contrib/postgres_fdw/expected/postgres_fdw.out | 87 ++
contrib/postgres_fdw/sql/postgres_fdw.sql  | 23 +++
src/backend/commands/tablecmds.c   |  6 ++
src/backend/utils/cache/plancache.c|  2 +
4 files changed, 118 insertions(+)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] pgsql: Invalidate cached plans on FDW option changes.

[Tom Lane]

Invalidate cached plans on FDW option changes.

This fixes problems where a plan must change but fails to do so,
as seen in a bug report from Rajkumar Raghuwanshi.

For ALTER FOREIGN TABLE OPTIONS, do this through the standard method of
forcing a relcache flush on the table.  For ALTER FOREIGN DATA WRAPPER
and ALTER SERVER, just flush the whole plan cache on any change in
pg_foreign_data_wrapper or pg_foreign_server.  That matches the way
we handle some other low-probability cases such as opclass changes, and
it's unclear that the case arises often enough to be worth working harder.
Besides, that gives a patch that is simple enough to back-patch with
confidence.

Back-patch to 9.3.  In principle we could apply the code change to 9.2 as
well, but (a) we lack postgres_fdw to test it with, (b) it's doubtful that
anyone is doing anything exciting enough with FDWs that far back to need
this desperately, and (c) the patch doesn't apply cleanly.

Patch originally by Amit Langote, reviewed by Etsuro Fujita and Ashutosh
Bapat, who each contributed substantial changes as well.

Discussion: 
https://postgr.es/m/CAKcux6m5cA6rRPTKkqVdJ-R=KKDfe35Q_ZuUqxDSV_4hwga=o...@mail.gmail.com

Branch
--
REL9_4_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/e4380e4cf68a647d87f0e6207b513d49e802b45c

Modified Files
--
contrib/postgres_fdw/expected/postgres_fdw.out | 57 ++
contrib/postgres_fdw/sql/postgres_fdw.sql  | 15 +++
src/backend/commands/tablecmds.c   |  6 +++
src/backend/utils/cache/plancache.c|  2 +
4 files changed, 80 insertions(+)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] pgsql: Invalidate cached plans on FDW option changes.

[Tom Lane]

Invalidate cached plans on FDW option changes.

This fixes problems where a plan must change but fails to do so,
as seen in a bug report from Rajkumar Raghuwanshi.

For ALTER FOREIGN TABLE OPTIONS, do this through the standard method of
forcing a relcache flush on the table.  For ALTER FOREIGN DATA WRAPPER
and ALTER SERVER, just flush the whole plan cache on any change in
pg_foreign_data_wrapper or pg_foreign_server.  That matches the way
we handle some other low-probability cases such as opclass changes, and
it's unclear that the case arises often enough to be worth working harder.
Besides, that gives a patch that is simple enough to back-patch with
confidence.

Back-patch to 9.3.  In principle we could apply the code change to 9.2 as
well, but (a) we lack postgres_fdw to test it with, (b) it's doubtful that
anyone is doing anything exciting enough with FDWs that far back to need
this desperately, and (c) the patch doesn't apply cleanly.

Patch originally by Amit Langote, reviewed by Etsuro Fujita and Ashutosh
Bapat, who each contributed substantial changes as well.

Discussion: 
https://postgr.es/m/CAKcux6m5cA6rRPTKkqVdJ-R=KKDfe35Q_ZuUqxDSV_4hwga=o...@mail.gmail.com

Branch
--
REL9_6_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/4103a2f200d6050b6c71e5c3c79c70ea98020307

Modified Files
--
contrib/postgres_fdw/expected/postgres_fdw.out | 88 ++
contrib/postgres_fdw/sql/postgres_fdw.sql  | 23 +++
src/backend/commands/tablecmds.c   |  6 ++
src/backend/utils/cache/plancache.c|  2 +
4 files changed, 119 insertions(+)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Re: [COMMITTERS] pgsql: Update copyright for 2017

[Bruce Momjian]

On Wed, Jan  4, 2017 at 10:05:10AM -0500, Tom Lane wrote:
> Andres Freund  writes:
> > On 2017-01-03 13:02:28 -0500, Bruce Momjian wrote:
> >> Yeah, I was doing parallel pulls of different branches in git via shell
> >> script, and it seems the size of this commit showed me that doesn't
> >> work.  Sorry.
> 
> > Shouldn't you check the results of something like this before pushing?
> > Sorry for piling on, but that seems like a quite critical step.
> 
> Actually, my takeaway from this was "don't ever use git reset on the repo".
> "git revert" would have been much safer.  Yeah, it would have meant that
> git blame on the 9.2 branch would have some useless noise, but how much
> does anyone still care about that?

FYI, my takeaway is that you can't run parallel 'git pull' operations on
different branches checked out of the same tree, at least as setup from
instructions on our wiki.   Such parallel operations generate messages
indicating someone else is working on the tree, but I now realize those
are _warnings_ and this behavior should be avoided.  Normally it works
fine, but for a big commit, it can move a changeset from one branch to
another, with disastrous consequences.

Yes, I should have checked more, but I often do a pull before a push as
another check, so that can mess it up too.  Basically, if your tools are
being used improperly, checking can make things worse too.

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+  Ancient Roman grave inscription +


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] pgsql: Repair commit b81b5a96f424531b97cdd1dba97d9d1b9c9d372e.

[Robert Haas]

Repair commit b81b5a96f424531b97cdd1dba97d9d1b9c9d372e.

This commit purported to use a variable hash seed for Partial
HashAggregate, but actually did the opposite - it made us use a
variable seed for any HashAggregate that is NOT partial.  Woops.

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/0355e6f3107a5be9b5f0873f08527bad361d9d8f

Modified Files
--
src/backend/executor/nodeAgg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers