Re: [COMMITTERS] pgsql: Fix document bug regarding read only transactions.

[Tatsuo Ishii]

> You're right that the statement is irrelevant in the context of what
> a standby can or can't do, but what I'm worried about is that someone
> will read it and believe that it represents the whole truth about
> what read-only master transactions can do.  The previous wording was
> also irrelevant to the context of a standby, and yet this whole thread
> exists because somebody complained that it's an inaccurate description
> of the restrictions on such a master transaction.  Well, it's still
> inaccurate.

Then I think we should add more commands including ANALYZE, VACUUM and
strong LOCKS here. There's no specific reason to pick up only
nextval(), LISTEN and NOTIFY.

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp


-- 
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: Make configure check for IPC::Run when --enable-tap-tests is spe

[Tom Lane]

Make configure check for IPC::Run when --enable-tap-tests is specified.

The TAP tests mostly don't work without IPC::Run, and the reason for
the failure is not immediately obvious from the error messages you get.
So teach configure to reject --enable-tap-tests unless IPC::Run exists.
Mostly this just involves adding ax_prog_perl_modules.m4 from the GNU
autoconf archives.

This was discussed last year, but we held off on the theory that we might
be switching to CMake soon.  That's evidently not happening for v10,
so let's absorb this now.

Eugene Kazakov and Michael Paquier

Discussion: https://postgr.es/m/56bddc20.9020...@postgrespro.ru
Discussion: 
https://postgr.es/m/cab7npqrvkg_cr4dy_amfe6dxcr6f7ygy2goa2atju4xkerd...@mail.gmail.com

Branch
--
master

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

Modified Files
--
aclocal.m4 |  1 +
config/ax_prog_perl_modules.m4 | 77 +
configure  | 78 ++
configure.in   |  3 ++
4 files changed, 159 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: Fix low-probability leaks of PGresult objects in the backend.

[Tom Lane]

Fix low-probability leaks of PGresult objects in the backend.

We had three occurrences of essentially the same coding pattern
wherein we tried to retrieve a query result from a libpq connection
without blocking.  In the case where PQconsumeInput failed (typically
indicating a lost connection), all three loops simply gave up and
returned, forgetting to clear any previously-collected PGresult
object.  Since those are malloc'd not palloc'd, the oversight results
in a process-lifespan memory leak.

One instance, in libpqwalreceiver, is of little significance because
the walreceiver process would just quit anyway if its connection fails.
But we might as well fix it.

The other two instances, in postgres_fdw, are somewhat more worrisome
because at least in principle the scenario could be repeated, allowing
the amount of memory leaked to build up to something worth worrying
about.  Moreover, in these cases the loops contain CHECK_FOR_INTERRUPTS
calls, as well as other calls that could potentially elog(ERROR),
providing another way to exit without having cleared the PGresult.
Here we need to add PG_TRY logic similar to what exists in quite a
few other places in postgres_fdw.

Coverity noted the libpqwalreceiver bug; I found the other two cases
by checking all calls of PQconsumeInput.

Back-patch to all supported versions as appropriate (9.2 lacks
postgres_fdw, so this is really quite unexciting for that branch).

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

Branch
--
REL9_2_STABLE

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

Modified Files
--
.../replication/libpqwalreceiver/libpqwalreceiver.c| 14 ++
1 file changed, 10 insertions(+), 4 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: Fix low-probability leaks of PGresult objects in the backend.

[Tom Lane]

Fix low-probability leaks of PGresult objects in the backend.

We had three occurrences of essentially the same coding pattern
wherein we tried to retrieve a query result from a libpq connection
without blocking.  In the case where PQconsumeInput failed (typically
indicating a lost connection), all three loops simply gave up and
returned, forgetting to clear any previously-collected PGresult
object.  Since those are malloc'd not palloc'd, the oversight results
in a process-lifespan memory leak.

One instance, in libpqwalreceiver, is of little significance because
the walreceiver process would just quit anyway if its connection fails.
But we might as well fix it.

The other two instances, in postgres_fdw, are somewhat more worrisome
because at least in principle the scenario could be repeated, allowing
the amount of memory leaked to build up to something worth worrying
about.  Moreover, in these cases the loops contain CHECK_FOR_INTERRUPTS
calls, as well as other calls that could potentially elog(ERROR),
providing another way to exit without having cleared the PGresult.
Here we need to add PG_TRY logic similar to what exists in quite a
few other places in postgres_fdw.

Coverity noted the libpqwalreceiver bug; I found the other two cases
by checking all calls of PQconsumeInput.

Back-patch to all supported versions as appropriate (9.2 lacks
postgres_fdw, so this is really quite unexciting for that branch).

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

Branch
--
REL9_5_STABLE

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

Modified Files
--
contrib/postgres_fdw/connection.c  | 154 -
.../libpqwalreceiver/libpqwalreceiver.c|  14 +-
2 files changed, 102 insertions(+), 66 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: Fix low-probability leaks of PGresult objects in the backend.

[Tom Lane]

Fix low-probability leaks of PGresult objects in the backend.

We had three occurrences of essentially the same coding pattern
wherein we tried to retrieve a query result from a libpq connection
without blocking.  In the case where PQconsumeInput failed (typically
indicating a lost connection), all three loops simply gave up and
returned, forgetting to clear any previously-collected PGresult
object.  Since those are malloc'd not palloc'd, the oversight results
in a process-lifespan memory leak.

One instance, in libpqwalreceiver, is of little significance because
the walreceiver process would just quit anyway if its connection fails.
But we might as well fix it.

The other two instances, in postgres_fdw, are somewhat more worrisome
because at least in principle the scenario could be repeated, allowing
the amount of memory leaked to build up to something worth worrying
about.  Moreover, in these cases the loops contain CHECK_FOR_INTERRUPTS
calls, as well as other calls that could potentially elog(ERROR),
providing another way to exit without having cleared the PGresult.
Here we need to add PG_TRY logic similar to what exists in quite a
few other places in postgres_fdw.

Coverity noted the libpqwalreceiver bug; I found the other two cases
by checking all calls of PQconsumeInput.

Back-patch to all supported versions as appropriate (9.2 lacks
postgres_fdw, so this is really quite unexciting for that branch).

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

Branch
--
REL9_6_STABLE

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

Modified Files
--
contrib/postgres_fdw/connection.c  | 154 -
.../libpqwalreceiver/libpqwalreceiver.c|  14 +-
2 files changed, 102 insertions(+), 66 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: Fix low-probability leaks of PGresult objects in the backend.

[Tom Lane]

Fix low-probability leaks of PGresult objects in the backend.

We had three occurrences of essentially the same coding pattern
wherein we tried to retrieve a query result from a libpq connection
without blocking.  In the case where PQconsumeInput failed (typically
indicating a lost connection), all three loops simply gave up and
returned, forgetting to clear any previously-collected PGresult
object.  Since those are malloc'd not palloc'd, the oversight results
in a process-lifespan memory leak.

One instance, in libpqwalreceiver, is of little significance because
the walreceiver process would just quit anyway if its connection fails.
But we might as well fix it.

The other two instances, in postgres_fdw, are somewhat more worrisome
because at least in principle the scenario could be repeated, allowing
the amount of memory leaked to build up to something worth worrying
about.  Moreover, in these cases the loops contain CHECK_FOR_INTERRUPTS
calls, as well as other calls that could potentially elog(ERROR),
providing another way to exit without having cleared the PGresult.
Here we need to add PG_TRY logic similar to what exists in quite a
few other places in postgres_fdw.

Coverity noted the libpqwalreceiver bug; I found the other two cases
by checking all calls of PQconsumeInput.

Back-patch to all supported versions as appropriate (9.2 lacks
postgres_fdw, so this is really quite unexciting for that branch).

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

Branch
--
REL9_3_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/99090e977d51107b25ba1670801975d6d1495d74

Modified Files
--
contrib/postgres_fdw/connection.c  | 154 -
.../libpqwalreceiver/libpqwalreceiver.c|  14 +-
2 files changed, 102 insertions(+), 66 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: Fix low-probability leaks of PGresult objects in the backend.

[Tom Lane]

Fix low-probability leaks of PGresult objects in the backend.

We had three occurrences of essentially the same coding pattern
wherein we tried to retrieve a query result from a libpq connection
without blocking.  In the case where PQconsumeInput failed (typically
indicating a lost connection), all three loops simply gave up and
returned, forgetting to clear any previously-collected PGresult
object.  Since those are malloc'd not palloc'd, the oversight results
in a process-lifespan memory leak.

One instance, in libpqwalreceiver, is of little significance because
the walreceiver process would just quit anyway if its connection fails.
But we might as well fix it.

The other two instances, in postgres_fdw, are somewhat more worrisome
because at least in principle the scenario could be repeated, allowing
the amount of memory leaked to build up to something worth worrying
about.  Moreover, in these cases the loops contain CHECK_FOR_INTERRUPTS
calls, as well as other calls that could potentially elog(ERROR),
providing another way to exit without having cleared the PGresult.
Here we need to add PG_TRY logic similar to what exists in quite a
few other places in postgres_fdw.

Coverity noted the libpqwalreceiver bug; I found the other two cases
by checking all calls of PQconsumeInput.

Back-patch to all supported versions as appropriate (9.2 lacks
postgres_fdw, so this is really quite unexciting for that branch).

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

Branch
--
REL9_4_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/8e7d5845205e485328db4b7cb9b8411a96e95b80

Modified Files
--
contrib/postgres_fdw/connection.c  | 154 -
.../libpqwalreceiver/libpqwalreceiver.c|  14 +-
2 files changed, 102 insertions(+), 66 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: doc: remove mention of Windows junction points by pg_upgrade

[Bruce Momjian]

doc:  remove mention of Windows junction points by pg_upgrade

pg_upgrade never used Windows junction points but instead always used
Windows hard links.

Reported-by: Adrian Klaver

Discussion: https://postgr.es/m/6a638c60-90bb-4921-8ee4-5fdad68f8...@aklaver.com

Backpatch-through: 9.3, where the mention first appeared

Branch
--
REL9_3_STABLE

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

Modified Files
--
doc/src/sgml/pgupgrade.sgml | 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

[COMMITTERS] pgsql: doc: remove mention of Windows junction points by pg_upgrade

[Bruce Momjian]

doc:  remove mention of Windows junction points by pg_upgrade

pg_upgrade never used Windows junction points but instead always used
Windows hard links.

Reported-by: Adrian Klaver

Discussion: https://postgr.es/m/6a638c60-90bb-4921-8ee4-5fdad68f8...@aklaver.com

Backpatch-through: 9.3, where the mention first appeared

Branch
--
REL9_4_STABLE

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

Modified Files
--
doc/src/sgml/pgupgrade.sgml | 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

[COMMITTERS] pgsql: doc: remove mention of Windows junction points by pg_upgrade

[Bruce Momjian]

doc:  remove mention of Windows junction points by pg_upgrade

pg_upgrade never used Windows junction points but instead always used
Windows hard links.

Reported-by: Adrian Klaver

Discussion: https://postgr.es/m/6a638c60-90bb-4921-8ee4-5fdad68f8...@aklaver.com

Backpatch-through: 9.3, where the mention first appeared

Branch
--
REL9_5_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/85f2f543a81aebd1bc214679693c8720ad462fcd

Modified Files
--
doc/src/sgml/ref/pgupgrade.sgml | 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

[COMMITTERS] pgsql: doc: remove mention of Windows junction points by pg_upgrade

[Bruce Momjian]

doc:  remove mention of Windows junction points by pg_upgrade

pg_upgrade never used Windows junction points but instead always used
Windows hard links.

Reported-by: Adrian Klaver

Discussion: https://postgr.es/m/6a638c60-90bb-4921-8ee4-5fdad68f8...@aklaver.com

Backpatch-through: 9.3, where the mention first appeared

Branch
--
REL9_6_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/1798dd153d6f513c56c2888bcd72f3de854f4d78

Modified Files
--
doc/src/sgml/ref/pgupgrade.sgml | 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

[COMMITTERS] pgsql: doc: remove mention of Windows junction points by pg_upgrade

[Bruce Momjian]

doc:  remove mention of Windows junction points by pg_upgrade

pg_upgrade never used Windows junction points but instead always used
Windows hard links.

Reported-by: Adrian Klaver

Discussion: https://postgr.es/m/6a638c60-90bb-4921-8ee4-5fdad68f8...@aklaver.com

Backpatch-through: 9.3, where the mention first appeared

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/07fb943335f3cdd11a9146ae6fdee237cc83c5f6

Modified Files
--
doc/src/sgml/ref/pgupgrade.sgml | 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

[COMMITTERS] pgsql: docs: Fix pg_upgrade standby server upgrade docs

[Bruce Momjian]

docs:  Fix pg_upgrade standby server upgrade docs

It was unsafe to instruct users to start/stop the server after
pg_upgrade was run but before the standby servers were rsync'ed.  The
new instructions avoid this.

RELEASE NOTES:  This fix should be mentioned in the minor release notes.

Reported-by: Dmitriy Sarafannikov and Sergey Burladyan

Discussion: https://postgr.es/m/87wp8o506b.fsf@seb.koffice.internal

Backpatch-through: 9.5, where standby server upgrade instructions first appeared

Branch
--
master

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

Modified Files
--
doc/src/sgml/ref/pgupgrade.sgml | 33 +++--
1 file changed, 15 insertions(+), 18 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: docs: Fix pg_upgrade standby server upgrade docs

[Bruce Momjian]

docs:  Fix pg_upgrade standby server upgrade docs

It was unsafe to instruct users to start/stop the server after
pg_upgrade was run but before the standby servers were rsync'ed.  The
new instructions avoid this.

RELEASE NOTES:  This fix should be mentioned in the minor release notes.

Reported-by: Dmitriy Sarafannikov and Sergey Burladyan

Discussion: https://postgr.es/m/87wp8o506b.fsf@seb.koffice.internal

Backpatch-through: 9.5, where standby server upgrade instructions first appeared

Branch
--
REL9_5_STABLE

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

Modified Files
--
doc/src/sgml/ref/pgupgrade.sgml | 33 +++--
1 file changed, 15 insertions(+), 18 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: docs: Fix pg_upgrade standby server upgrade docs

[Bruce Momjian]

docs:  Fix pg_upgrade standby server upgrade docs

It was unsafe to instruct users to start/stop the server after
pg_upgrade was run but before the standby servers were rsync'ed.  The
new instructions avoid this.

RELEASE NOTES:  This fix should be mentioned in the minor release notes.

Reported-by: Dmitriy Sarafannikov and Sergey Burladyan

Discussion: https://postgr.es/m/87wp8o506b.fsf@seb.koffice.internal

Backpatch-through: 9.5, where standby server upgrade instructions first appeared

Branch
--
REL9_6_STABLE

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

Modified Files
--
doc/src/sgml/ref/pgupgrade.sgml | 33 +++--
1 file changed, 15 insertions(+), 18 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: Rename function for consistency

[Alvaro Herrera]

Rename function for consistency

Avoid using prefix "staext" when everything else uses "statext".

Author: Kyotaro HORIGUCHI
Discussion: 
https://postgr.es/m/20170615.140041.165731947.horiguchi.kyot...@lab.ntt.co.jp

Branch
--
master

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

Modified Files
--
src/backend/statistics/dependencies.c | 6 +++---
src/include/statistics/statistics.h   | 2 +-
2 files changed, 4 insertions(+), 4 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: psql: Improve display of "for all tables" publications

[Peter Eisentraut]

psql: Improve display of "for all tables" publications

Show "All tables" property in \dRp and \dRp+.  Don't list tables for
such publications in \dRp+, since it's redundant and the list could be
very long.

Author: Masahiko Sawada 
Author: Jeff Janes 

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/915379c3c2613f2b24d4e9c6fa79a43e7c6a86ec

Modified Files
--
src/bin/psql/describe.c   | 62 +++
src/test/regress/expected/publication.out | 83 +--
src/test/regress/sql/publication.sql  |  1 +
3 files changed, 75 insertions(+), 71 deletions(-)


-- 
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: Fix problems related to RangeTblEntry members enrname and enrtup

[Robert Haas]

On Thu, Jun 15, 2017 at 10:17 AM, Tom Lane  wrote:
> Robert Haas  writes:
>> On Wed, Jun 14, 2017 at 4:30 PM, Tom Lane  wrote:
>>> This really should have involved a catversion bump.  But we just
>>> had one earlier today, so in practice it might not matter.
>
>> Oh, because of stored rules using the old RangeTblEntry serialization
>> format?  Sorry, I totally missed that.
>
> Yeah, exactly.  In practice I'm not sure a stored rule/view could contain
> an RTE_NAMEDTUPLESTORE RangeTblEntry, but if it did, there'd be a problem.

I think that's not possible, so we're probably fine, even apart from
the fact that we've bumped catversion multiple times since beta1.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
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: Fix problems related to RangeTblEntry members enrname and enrtup

[Tom Lane]

Robert Haas  writes:
> On Wed, Jun 14, 2017 at 4:30 PM, Tom Lane  wrote:
>> This really should have involved a catversion bump.  But we just
>> had one earlier today, so in practice it might not matter.

> Oh, because of stored rules using the old RangeTblEntry serialization
> format?  Sorry, I totally missed that.

Yeah, exactly.  In practice I'm not sure a stored rule/view could contain
an RTE_NAMEDTUPLESTORE RangeTblEntry, but if it did, there'd be a problem.

regards, tom lane


-- 
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: Fix document bug regarding read only transactions.

[Tom Lane]

Tatsuo Ishii  writes:
>> Right, but what I think it is comparing is a read-only transaction
>> on the master and a transaction on the standby.  The former can do
>> nextval() on temp sequences, the latter can't.

> But we cannot create temp sequences on stanbys in the first place.
> Still do you think there's value to refer to nextval() on temp
> sequences here?

You're right that the statement is irrelevant in the context of what
a standby can or can't do, but what I'm worried about is that someone
will read it and believe that it represents the whole truth about
what read-only master transactions can do.  The previous wording was
also irrelevant to the context of a standby, and yet this whole thread
exists because somebody complained that it's an inaccurate description
of the restrictions on such a master transaction.  Well, it's still
inaccurate.

regards, tom lane


-- 
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: Fix problems related to RangeTblEntry members enrname and enrtup

[Robert Haas]

On Wed, Jun 14, 2017 at 4:30 PM, Tom Lane  wrote:
> Robert Haas  writes:
>> Fix problems related to RangeTblEntry members enrname and enrtuples.
>> Commit 18ce3a4ab22d2984f8540ab480979c851dae5338 failed to update
>> the comments in parsenodes.h for the new members, and made only
>> incomplete updates to src/backend/nodes
>
> This really should have involved a catversion bump.  But we just
> had one earlier today, so in practice it might not matter.

Oh, because of stored rules using the old RangeTblEntry serialization
format?  Sorry, I totally missed that.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
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: Fix typo in code comment

[Peter Eisentraut]

Fix typo in code comment

Author: Daniel Gustafsson 

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/6c6a1149b5662f685ddbb0c6dc83eb110992044a

Modified Files
--
src/interfaces/ecpg/pgtypeslib/datetime.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

[COMMITTERS] pgsql: Remove unnecessary IPC::Run inclusion

[Peter Eisentraut]

Remove unnecessary IPC::Run inclusion

This is no longer needed because the tests use PostgresNode.

Reported-by: Michael Paquier 

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/878b7d9eaa9cbf5f121f9ee8676d82b22decedf0

Modified Files
--
src/test/ssl/t/001_ssltests.pl | 13 -
1 file changed, 13 deletions(-)


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