pgsql: Repair double-free in SP-GIST rescan (bug #15378)
Repair double-free in SP-GIST rescan (bug #15378) spgrescan would first reset traversalCxt, and then traverse a potentially non-empty stack containing pointers to traversalValues which had been allocated in those contexts, freeing them a second time. This bug originates in commit ccd6eb49a where traversalValue was introduced. Repair by traversing the stack before the context reset; this isn't ideal, since it means doing retail pfree in a context that's about to be reset, but the freeing of a stack entry is also done in other places in the code during the scan so it's not worth trying to refactor it further. Regression test added. Backpatch to 9.6 where the problem was introduced. Per bug #15378; analysis and patch by me, originally from a report on IRC by user velix; see also PostGIS ticket #4174; review by Alexander Korotkov. Discussion: https://postgr.es/m/153663176628.23136.11901365223750051...@wrigleys.postgresql.org Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/e331d6712f0224160d2699591704ddcc3ef2d67b Modified Files -- src/backend/access/spgist/spgscan.c | 10 +++--- src/test/regress/expected/spgist.out | 18 ++ src/test/regress/sql/spgist.sql | 15 +++ 3 files changed, 40 insertions(+), 3 deletions(-)
pgsql: Repair double-free in SP-GIST rescan (bug #15378)
Repair double-free in SP-GIST rescan (bug #15378) spgrescan would first reset traversalCxt, and then traverse a potentially non-empty stack containing pointers to traversalValues which had been allocated in those contexts, freeing them a second time. This bug originates in commit ccd6eb49a where traversalValue was introduced. Repair by traversing the stack before the context reset; this isn't ideal, since it means doing retail pfree in a context that's about to be reset, but the freeing of a stack entry is also done in other places in the code during the scan so it's not worth trying to refactor it further. Regression test added. Backpatch to 9.6 where the problem was introduced. Per bug #15378; analysis and patch by me, originally from a report on IRC by user velix; see also PostGIS ticket #4174; review by Alexander Korotkov. Discussion: https://postgr.es/m/153663176628.23136.11901365223750051...@wrigleys.postgresql.org Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/84a3a1e55c86a104a8e259a43ed31814e010954f Modified Files -- src/backend/access/spgist/spgscan.c | 10 +++--- src/test/regress/expected/spgist.out | 18 ++ src/test/regress/sql/spgist.sql | 15 +++ 3 files changed, 40 insertions(+), 3 deletions(-)
pgsql: Repair double-free in SP-GIST rescan (bug #15378)
Repair double-free in SP-GIST rescan (bug #15378) spgrescan would first reset traversalCxt, and then traverse a potentially non-empty stack containing pointers to traversalValues which had been allocated in those contexts, freeing them a second time. This bug originates in commit ccd6eb49a where traversalValue was introduced. Repair by traversing the stack before the context reset; this isn't ideal, since it means doing retail pfree in a context that's about to be reset, but the freeing of a stack entry is also done in other places in the code during the scan so it's not worth trying to refactor it further. Regression test added. Backpatch to 9.6 where the problem was introduced. Per bug #15378; analysis and patch by me, originally from a report on IRC by user velix; see also PostGIS ticket #4174; review by Alexander Korotkov. Discussion: https://postgr.es/m/153663176628.23136.11901365223750051...@wrigleys.postgresql.org Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/500d49794f1f61cb20f485bd5c5052c122e58cf9 Modified Files -- src/backend/access/spgist/spgscan.c | 10 +++--- src/test/regress/expected/spgist.out | 18 ++ src/test/regress/sql/spgist.sql | 15 +++ 3 files changed, 40 insertions(+), 3 deletions(-)
pgsql: Repair double-free in SP-GIST rescan (bug #15378)
Repair double-free in SP-GIST rescan (bug #15378) spgrescan would first reset traversalCxt, and then traverse a potentially non-empty stack containing pointers to traversalValues which had been allocated in those contexts, freeing them a second time. This bug originates in commit ccd6eb49a where traversalValue was introduced. Repair by traversing the stack before the context reset; this isn't ideal, since it means doing retail pfree in a context that's about to be reset, but the freeing of a stack entry is also done in other places in the code during the scan so it's not worth trying to refactor it further. Regression test added. Backpatch to 9.6 where the problem was introduced. Per bug #15378; analysis and patch by me, originally from a report on IRC by user velix; see also PostGIS ticket #4174; review by Alexander Korotkov. Discussion: https://postgr.es/m/153663176628.23136.11901365223750051...@wrigleys.postgresql.org Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/c02b56869439281d139d47dae784e3f7cf765f2d Modified Files -- src/backend/access/spgist/spgscan.c | 10 +++--- src/test/regress/expected/spgist.out | 18 ++ src/test/regress/sql/spgist.sql | 15 +++ 3 files changed, 40 insertions(+), 3 deletions(-)
pgsql: Support building with Visual Studio 2017
Support building with Visual Studio 2017 Haribabu Kommi, reviewed by Takeshi Ideriha and Christian Ullrich Now backpatched to 9.4 and 9.3 Branch -- REL9_4_STABLE Details --- https://git.postgresql.org/pg/commitdiff/19acfd6528bcbf55ad996397177a1f2a16001c25 Modified Files -- doc/src/sgml/install-windows.sgml | 16 +--- src/tools/msvc/MSBuildProject.pm | 23 +++ src/tools/msvc/README | 13 +++-- src/tools/msvc/Solution.pm| 26 ++ src/tools/msvc/VSObjectFactory.pm | 13 + 5 files changed, 78 insertions(+), 13 deletions(-)
pgsql: Support building with Visual Studio 2017
Support building with Visual Studio 2017 Haribabu Kommi, reviewed by Takeshi Ideriha and Christian Ullrich Now backpatched to 9.4 and 9.3 Branch -- REL9_3_STABLE Details --- https://git.postgresql.org/pg/commitdiff/48c978f3ed20961a69189eab2e26e0fa0f54986f Modified Files -- doc/src/sgml/install-windows.sgml | 16 +--- src/tools/msvc/MSBuildProject.pm | 23 +++ src/tools/msvc/README | 13 +++-- src/tools/msvc/Solution.pm| 26 ++ src/tools/msvc/VSObjectFactory.pm | 13 + 5 files changed, 78 insertions(+), 13 deletions(-)
pgsql: Support building with Visual Studio 2017
Support building with Visual Studio 2017 Haribabu Kommi, reviewed by Takeshi Ideriha and Christian Ullrich Backpatch to 9.6 Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/f6c268c4894bba9d1bbc5338407febaaad0dbd04 Modified Files -- doc/src/sgml/install-windows.sgml | 16 +--- src/tools/msvc/MSBuildProject.pm | 23 +++ src/tools/msvc/README | 13 +++-- src/tools/msvc/Solution.pm| 26 ++ src/tools/msvc/VSObjectFactory.pm | 13 + 5 files changed, 78 insertions(+), 13 deletions(-)
pgsql: Support building with Visual Studio 2015
Support building with Visual Studio 2015 Adjust the way we detect the locale. As a result the minumum Windows version supported by VS2015 and later is Windows Vista. Add some tweaks to remove new compiler warnings. Remove documentation references to the now obsolete msysGit. Michael Paquier, somewhat edited by me, reviewed by Christian Ullrich. Rather belated backpatch to 9.4 and 9.3 Branch -- REL9_4_STABLE Details --- https://git.postgresql.org/pg/commitdiff/9ca32a6ebc12d91a4df314e47bb1faf933e5bbb4 Modified Files -- doc/src/sgml/install-windows.sgml | 29 + src/backend/port/win32/crashdump.c| 14 src/bin/pg_basebackup/pg_basebackup.c | 9 -- src/include/port/win32.h | 22 ++--- src/port/chklocale.c | 61 +++ src/port/win32env.c | 5 ++- src/tools/msvc/MSBuildProject.pm | 23 + src/tools/msvc/Solution.pm| 26 +++ src/tools/msvc/VSObjectFactory.pm | 12 +-- 9 files changed, 166 insertions(+), 35 deletions(-)
pgsql: Support building with Visual Studio 2015
Support building with Visual Studio 2015 Adjust the way we detect the locale. As a result the minumum Windows version supported by VS2015 and later is Windows Vista. Add some tweaks to remove new compiler warnings. Remove documentation references to the now obsolete msysGit. Michael Paquier, somewhat edited by me, reviewed by Christian Ullrich. Rather belated backpatch to 9.4 and 9.3 Branch -- REL9_3_STABLE Details --- https://git.postgresql.org/pg/commitdiff/0482578328288220c01b3f38e55fd866f8351b25 Modified Files -- doc/src/sgml/install-windows.sgml | 29 + src/backend/port/win32/crashdump.c| 14 src/bin/pg_basebackup/pg_basebackup.c | 9 -- src/include/port/win32.h | 22 ++--- src/port/chklocale.c | 61 +++ src/port/win32env.c | 5 ++- src/tools/msvc/MSBuildProject.pm | 23 + src/tools/msvc/Solution.pm| 26 +++ src/tools/msvc/VSObjectFactory.pm | 12 +-- 9 files changed, 166 insertions(+), 35 deletions(-)
pgsql: Remove ruleutils.c's special case for BIT [VARYING] literals.
Remove ruleutils.c's special case for BIT [VARYING] literals.
Up to now, get_const_expr() insisted on prefixing BIT and VARBIT
literals with 'B'. That's not really necessary, because we always
append explicit-cast syntax to identify the constant's type.
Moreover, it's subtly wrong for VARBIT, because the parser will
interpret B'...' as '...'::"bit"; see make_const() which explicitly
assigns type BITOID for a T_BitString literal. So what had been
a simple VARBIT literal is reconstructed as ('...'::"bit")::varbit,
which is not the same thing, at least not before constant folding.
This results in odd differences after dump/restore, as complained
of by the patch submitter, and it could result in actual failures in
partitioning or inheritance DDL operations (see commit 542320c2b,
which repaired similar misbehaviors for some other data types).
Fixing it is pretty easy: just remove the special case and let the
default code path handle these types. We could have kept the special
case for BIT only, but there seems little point in that.
Like the previous patch, I judge that back-patching this into stable
branches wouldn't be a good idea. However, it seems not quite too
late for v11, so let's fix it there.
Paul Guo, reviewed by Davy Machado and John Naylor, minor adjustments
by me
Discussion:
https://postgr.es/m/CABQrizdTra=2jeqa6+ms1d1k1kqw+aibbhc9treuzrx2jzx...@mail.gmail.com
Branch
--
REL_11_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/224256f890c71b809c1a6b62b426fc8ceec7b0da
Modified Files
--
contrib/btree_gist/expected/bit.out| 6 +++---
contrib/btree_gist/expected/varbit.out | 6 +++---
src/backend/utils/adt/ruleutils.c | 5 -
src/test/regress/expected/bit.out | 23 +++
src/test/regress/expected/sanity_check.out | 1 +
src/test/regress/sql/bit.sql | 11 +++
6 files changed, 41 insertions(+), 11 deletions(-)
pgsql: Remove ruleutils.c's special case for BIT [VARYING] literals.
Remove ruleutils.c's special case for BIT [VARYING] literals.
Up to now, get_const_expr() insisted on prefixing BIT and VARBIT
literals with 'B'. That's not really necessary, because we always
append explicit-cast syntax to identify the constant's type.
Moreover, it's subtly wrong for VARBIT, because the parser will
interpret B'...' as '...'::"bit"; see make_const() which explicitly
assigns type BITOID for a T_BitString literal. So what had been
a simple VARBIT literal is reconstructed as ('...'::"bit")::varbit,
which is not the same thing, at least not before constant folding.
This results in odd differences after dump/restore, as complained
of by the patch submitter, and it could result in actual failures in
partitioning or inheritance DDL operations (see commit 542320c2b,
which repaired similar misbehaviors for some other data types).
Fixing it is pretty easy: just remove the special case and let the
default code path handle these types. We could have kept the special
case for BIT only, but there seems little point in that.
Like the previous patch, I judge that back-patching this into stable
branches wouldn't be a good idea. However, it seems not quite too
late for v11, so let's fix it there.
Paul Guo, reviewed by Davy Machado and John Naylor, minor adjustments
by me
Discussion:
https://postgr.es/m/CABQrizdTra=2jeqa6+ms1d1k1kqw+aibbhc9treuzrx2jzx...@mail.gmail.com
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/fedc97cdfd834a2137d9c5aa8e7f89e39546fc6b
Modified Files
--
contrib/btree_gist/expected/bit.out| 6 +++---
contrib/btree_gist/expected/varbit.out | 6 +++---
src/backend/utils/adt/ruleutils.c | 5 -
src/test/regress/expected/bit.out | 23 +++
src/test/regress/expected/sanity_check.out | 1 +
src/test/regress/sql/bit.sql | 11 +++
6 files changed, 41 insertions(+), 11 deletions(-)
pgsql: doc: adjust PG 11 release notes
doc: adjust PG 11 release notes Fixes for channel binding, SQL procedures, and pg_trgm. Backpatch-through: 11 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/0d45cd96fd0f3387d1bcf7e6f873c73c4f251df8 Modified Files -- doc/src/sgml/release-11.sgml | 15 +-- 1 file changed, 5 insertions(+), 10 deletions(-)
pgsql: doc: adjust PG 11 release notes
doc: adjust PG 11 release notes Fixes for channel binding, SQL procedures, and pg_trgm. Backpatch-through: 11 Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/293010a68afd5b3a1f1e7621d5c89ba422c21d09 Modified Files -- doc/src/sgml/release-11.sgml | 17 ++--- 1 file changed, 6 insertions(+), 11 deletions(-)
pgsql: Parse more strictly integer parameters from connection strings i
Parse more strictly integer parameters from connection strings in libpq The following parameters have been parsed in lossy ways when specified in a connection string processed by libpq: - connect_timeout - keepalives - keepalives_count - keepalives_idle - keepalives_interval - port Overflowing values or the presence of incorrect characters were not properly checked, leading to libpq trying to use such values and fail with unhelpful error messages. This commit hardens the parsing of those parameters so as it is possible to find easily incorrect values. Author: Fabien Coelho Reviewed-by: Peter Eisentraut, Michael Paquier Discussion: https://postgr.es/m/alpine.DEB.2.21.1808171206180.20841@lancre Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/e7a2217978d9cbb2149bfcb4ef1e45716cfcbefb Modified Files -- src/interfaces/libpq/fe-connect.c | 63 +-- 1 file changed, 54 insertions(+), 9 deletions(-)
pgsql: Add PQresultMemorySize function to report allocated size of a PG
Add PQresultMemorySize function to report allocated size of a PGresult. This number can be useful for application memory management, and the overhead to track it seems pretty trivial. Lars Kanis, reviewed by Pavel Stehule, some mods by me Discussion: https://postgr.es/m/fa16a288-9685-14f2-97c8-b8ac84365...@greiz-reinsdorf.de Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/2970afa6cf1057107c998bf3cdd1fbf6dc78cf6c Modified Files -- doc/src/sgml/libpq.sgml | 34 ++ src/interfaces/libpq/exports.txt | 1 + src/interfaces/libpq/fe-exec.c | 38 -- src/interfaces/libpq/libpq-fe.h | 1 + src/interfaces/libpq/libpq-int.h | 2 ++ 5 files changed, 70 insertions(+), 6 deletions(-)
