pgsql: Doc: Fix example related to partition pruning
Doc: Fix example related to partition pruning Append node has been removed in v12 when there would be only one subnode under it. Author: Amit Langote Discussion: https://postgr.es/m/ca+hiwqhhs62w8zufxf4nbjvmbocxynd-jwowp-tfo2ahvp3...@mail.gmail.com Backpatch-through: 12 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/f5daf7f3266ff5a92f1bf8d386bd5ac3d7d042d6 Modified Files -- doc/src/sgml/ddl.sgml | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
pgsql: Doc: Fix example related to partition pruning
Doc: Fix example related to partition pruning Append node has been removed in v12 when there would be only one subnode under it. Author: Amit Langote Discussion: https://postgr.es/m/ca+hiwqhhs62w8zufxf4nbjvmbocxynd-jwowp-tfo2ahvp3...@mail.gmail.com Backpatch-through: 12 Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/37ad1266147626bfe505b2c5b016497605915a8e Modified Files -- doc/src/sgml/ddl.sgml | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
pgsql: Make more stable regression tests of dummy_index_am for string v
Make more stable regression tests of dummy_index_am for string validations Several buildfarm members (crake, loach and spurfowl) are complaining about two queries looking up at pg_class.reloptions which trigger the validation routines for string reloptions with default values. This commit limits the routines to be triggered only when building an index with all custom options set in CREATE INDEX, which is sufficient for the coverage. Introduced by 640c198. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/e0afac124ec7026a49909436ebcfc2bd999852a8 Modified Files -- src/test/modules/dummy_index_am/expected/reloptions.out | 8 ++-- src/test/modules/dummy_index_am/sql/reloptions.sql | 10 +++--- 2 files changed, 13 insertions(+), 5 deletions(-)
pgsql: Add dummy_index_am to src/test/modules/
Add dummy_index_am to src/test/modules/ This includes more tests dedicated to relation options, bringing the coverage of this code close to 100%, and the module can be used for other purposes, like a base template for an index AM implementation. Author: Nikolay Sharplov, Michael Paquier Reviewed-by: Álvaro Herrera, Dent John Discussion: https://postgr.es/m/17071942.m9zZutALE6@x200m Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/640c19869f8c4b5c34d3982b5e1cd40e62abbb85 Modified Files -- src/test/modules/Makefile | 1 + src/test/modules/dummy_index_am/.gitignore | 3 + src/test/modules/dummy_index_am/Makefile | 20 ++ src/test/modules/dummy_index_am/README | 11 + .../modules/dummy_index_am/dummy_index_am--1.0.sql | 19 ++ src/test/modules/dummy_index_am/dummy_index_am.c | 312 + .../modules/dummy_index_am/dummy_index_am.control | 5 + .../modules/dummy_index_am/expected/reloptions.out | 115 src/test/modules/dummy_index_am/sql/reloptions.sql | 68 + src/tools/pgindent/typedefs.list | 1 + 10 files changed, 555 insertions(+)
pgsql: Allow definition of lock mode for custom reloptions
Allow definition of lock mode for custom reloptions Relation options can define a lock mode other than AccessExclusiveMode since 47167b7, but modules defining custom relation options did not really have a way to enforce that. Correct that by extending the current API set so as modules can define a custom lock mode. Author: Michael Paquier Reviewed-by: Kuntal Ghosh Discussion: https://postgr.es/m/20190920013831.gd1...@paquier.xyz Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/69f94108079d70093b59096a3ae0ad82c842b4c0 Modified Files -- contrib/bloom/blutils.c| 6 -- src/backend/access/common/reloptions.c | 28 src/include/access/reloptions.h| 11 +++ 3 files changed, 23 insertions(+), 22 deletions(-)
pgsql: Fix failure with lock mode used for custom relation options
Fix failure with lock mode used for custom relation options In-core relation options can use a custom lock mode since 47167b7, that has lowered the lock available for some autovacuum parameters. However it forgot to consider custom relation options. This causes failures with ALTER TABLE SET when changing a custom relation option, as its lock is not defined. The existing APIs to define a custom reloption does not allow to define a custom lock mode, so enforce its initialization to AccessExclusiveMode which should be safe enough in all cases. An upcoming patch will extend the existing APIs to allow a custom lock mode to be defined. The problem can be reproduced with bloom indexes, so add a test there. Reported-by: Nikolay Sharplov Analyzed-by: Thomas Munro, Michael Paquier Author: Michael Paquier Reviewed-by: Kuntal Ghosh Discussion: https://postgr.es/m/20190920013831.gd1...@paquier.xyz Backpatch-through: 9.6 Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/98b5c37852967bd28b1f102d4ac9bd0025e7c87d Modified Files -- contrib/bloom/expected/bloom.out | 1 + contrib/bloom/sql/bloom.sql| 1 + src/backend/access/common/reloptions.c | 7 +++ 3 files changed, 9 insertions(+)
pgsql: Fix failure with lock mode used for custom relation options
Fix failure with lock mode used for custom relation options In-core relation options can use a custom lock mode since 47167b7, that has lowered the lock available for some autovacuum parameters. However it forgot to consider custom relation options. This causes failures with ALTER TABLE SET when changing a custom relation option, as its lock is not defined. The existing APIs to define a custom reloption does not allow to define a custom lock mode, so enforce its initialization to AccessExclusiveMode which should be safe enough in all cases. An upcoming patch will extend the existing APIs to allow a custom lock mode to be defined. The problem can be reproduced with bloom indexes, so add a test there. Reported-by: Nikolay Sharplov Analyzed-by: Thomas Munro, Michael Paquier Author: Michael Paquier Reviewed-by: Kuntal Ghosh Discussion: https://postgr.es/m/20190920013831.gd1...@paquier.xyz Backpatch-through: 9.6 Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/707f38e38e8d4ee891bf52c2f9684f87c72b5234 Modified Files -- contrib/bloom/expected/bloom.out | 1 + contrib/bloom/sql/bloom.sql| 1 + src/backend/access/common/reloptions.c | 7 +++ 3 files changed, 9 insertions(+)
pgsql: Fix failure with lock mode used for custom relation options
Fix failure with lock mode used for custom relation options In-core relation options can use a custom lock mode since 47167b7, that has lowered the lock available for some autovacuum parameters. However it forgot to consider custom relation options. This causes failures with ALTER TABLE SET when changing a custom relation option, as its lock is not defined. The existing APIs to define a custom reloption does not allow to define a custom lock mode, so enforce its initialization to AccessExclusiveMode which should be safe enough in all cases. An upcoming patch will extend the existing APIs to allow a custom lock mode to be defined. The problem can be reproduced with bloom indexes, so add a test there. Reported-by: Nikolay Sharplov Analyzed-by: Thomas Munro, Michael Paquier Author: Michael Paquier Reviewed-by: Kuntal Ghosh Discussion: https://postgr.es/m/20190920013831.gd1...@paquier.xyz Backpatch-through: 9.6 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/736b84eede6cfdadf1114cf5a0e950d7f4986d82 Modified Files -- contrib/bloom/expected/bloom.out | 1 + contrib/bloom/sql/bloom.sql| 1 + src/backend/access/common/reloptions.c | 7 +++ 3 files changed, 9 insertions(+)
pgsql: Fix failure with lock mode used for custom relation options
Fix failure with lock mode used for custom relation options In-core relation options can use a custom lock mode since 47167b7, that has lowered the lock available for some autovacuum parameters. However it forgot to consider custom relation options. This causes failures with ALTER TABLE SET when changing a custom relation option, as its lock is not defined. The existing APIs to define a custom reloption does not allow to define a custom lock mode, so enforce its initialization to AccessExclusiveMode which should be safe enough in all cases. An upcoming patch will extend the existing APIs to allow a custom lock mode to be defined. The problem can be reproduced with bloom indexes, so add a test there. Reported-by: Nikolay Sharplov Analyzed-by: Thomas Munro, Michael Paquier Author: Michael Paquier Reviewed-by: Kuntal Ghosh Discussion: https://postgr.es/m/20190920013831.gd1...@paquier.xyz Backpatch-through: 9.6 Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/d4816800378452e125d4e1ca7dfdb598609ab992 Modified Files -- contrib/bloom/expected/bloom.out | 1 + contrib/bloom/sql/bloom.sql| 1 + src/backend/access/common/reloptions.c | 7 +++ 3 files changed, 9 insertions(+)
pgsql: Fix failure with lock mode used for custom relation options
Fix failure with lock mode used for custom relation options In-core relation options can use a custom lock mode since 47167b7, that has lowered the lock available for some autovacuum parameters. However it forgot to consider custom relation options. This causes failures with ALTER TABLE SET when changing a custom relation option, as its lock is not defined. The existing APIs to define a custom reloption does not allow to define a custom lock mode, so enforce its initialization to AccessExclusiveMode which should be safe enough in all cases. An upcoming patch will extend the existing APIs to allow a custom lock mode to be defined. The problem can be reproduced with bloom indexes, so add a test there. Reported-by: Nikolay Sharplov Analyzed-by: Thomas Munro, Michael Paquier Author: Michael Paquier Reviewed-by: Kuntal Ghosh Discussion: https://postgr.es/m/20190920013831.gd1...@paquier.xyz Backpatch-through: 9.6 Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/d01d4f23742bb7bfedeb47f16445c3478a9cd3d8 Modified Files -- contrib/bloom/expected/bloom.out | 1 + contrib/bloom/sql/bloom.sql| 1 + src/backend/access/common/reloptions.c | 7 +++ 3 files changed, 9 insertions(+)
pgsql: Fix bug in pairingheap_SpGistSearchItem_cmp()
Fix bug in pairingheap_SpGistSearchItem_cmp() Our item contains only so->numberOfNonNullOrderBys of distances. Reflect that in the loop upper bound. Discussion: https://postgr.es/m/53536807-784c-e029-6e92-6da802ab8d60%40postgrespro.ru Author: Nikita Glukhov Backpatch-through: 12 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/90c0987258264de07780f0329db2fce83098fba8 Modified Files -- src/backend/access/spgist/spgscan.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Fix bug in pairingheap_SpGistSearchItem_cmp()
Fix bug in pairingheap_SpGistSearchItem_cmp() Our item contains only so->numberOfNonNullOrderBys of distances. Reflect that in the loop upper bound. Discussion: https://postgr.es/m/53536807-784c-e029-6e92-6da802ab8d60%40postgrespro.ru Author: Nikita Glukhov Backpatch-through: 12 Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/8728552b291b8fe3778346fb4d4b7d1c8743f708 Modified Files -- src/backend/access/spgist/spgscan.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Rework WAL-reading supporting structs
Rework WAL-reading supporting structs The state-tracking of WAL reading in various places was pretty messy, mostly because the ancient physical-replication WAL reading code wasn't using the XLogReader abstraction. This led to some untidy code. Make it prettier by creating two additional supporting structs, WALSegmentContext and WALOpenSegment which keep track of WAL-reading state. This makes code cleaner, as well as supports more future cleanup. Author: Antonin Houska Reviewed-by: Álvaro Herrera and (older versions) Robert Haas Discussion: https://postgr.es/m/14984.1554998...@spoje.net Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/709d003fbd98b975a4fbcb4c5750fa6efaf9ad87 Modified Files -- src/backend/access/transam/twophase.c | 5 +- src/backend/access/transam/xlog.c | 17 +++-- src/backend/access/transam/xlogreader.c| 73 +++--- src/backend/access/transam/xlogutils.c | 30 src/backend/replication/logical/logical.c | 2 +- src/backend/replication/logical/logicalfuncs.c | 4 +- src/backend/replication/walsender.c| 102 - src/bin/pg_rewind/parsexlog.c | 21 ++--- src/bin/pg_waldump/pg_waldump.c| 68 +++-- src/include/access/xlogreader.h| 41 ++ src/include/access/xlogutils.h | 3 +- src/include/replication/logicalfuncs.h | 2 +- 12 files changed, 189 insertions(+), 179 deletions(-)
pgsql: Prevent bogus pullup of constant-valued functions returning comp
Prevent bogus pullup of constant-valued functions returning composite. Fix an oversight in commit 7266d0997: as it stood, the code failed when a function-in-FROM returns composite and can be simplified to a composite constant. For the moment, just test for composite result and abandon pullup if we see one. To make it actually work, we'd have to decompose the composite constant into per-column constants; which is surely do-able, but I'm not convinced it's worth the code space. Per report from Raúl Marín Rodríguez. Discussion: https://postgr.es/m/cam6_um4isp+bura5swodo_muegutms-kdfnkwgmryc5dgj9...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/a9ae99d0190960ce2d3dd3e5f10e7f4adc3cf203 Modified Files -- src/backend/optimizer/prep/prepjointree.c | 18 +++ src/test/regress/expected/join.out| 37 +++ src/test/regress/sql/join.sql | 19 3 files changed, 74 insertions(+)
pgsql: Speedup truncations of relation forks.
Speedup truncations of relation forks. When a relation is truncated, shared_buffers needs to be scanned so that any buffers for the relation forks are invalidated in it. Previously, shared_buffers was scanned for each relation forks, i.e., MAIN, FSM and VM, when VACUUM truncated off any empty pages at the end of relation or TRUNCATE truncated the relation in place. Since shared_buffers needed to be scanned multiple times, it could take a long time to finish those commands especially when shared_buffers was large. This commit changes the logic so that shared_buffers is scanned only one time for those three relation forks. Author: Kirk Jamison Reviewed-by: Masahiko Sawada, Thomas Munro, Alvaro Herrera, Takayuki Tsunakawa and Fujii Masao Discussion: https://postgr.es/m/D09B13F772D2274BB348A310EE3027C64E2067@g01jpexmbkw24 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/6d05086c0a79e50d8e91ed953626ec7280cd2481 Modified Files -- contrib/pg_visibility/pg_visibility.c | 11 +++- src/backend/access/heap/visibilitymap.c | 37 ++--- src/backend/catalog/storage.c | 87 +++ src/backend/storage/buffer/bufmgr.c | 30 +++ src/backend/storage/freespace/freespace.c | 42 +-- src/backend/storage/smgr/smgr.c | 37 ++--- src/include/access/visibilitymap.h| 3 +- src/include/storage/bufmgr.h | 4 +- src/include/storage/freespace.h | 3 +- src/include/storage/smgr.h| 4 +- 10 files changed, 172 insertions(+), 86 deletions(-)
pgsql: Don't disable ccache when building with coverage support
Don't disable ccache when building with coverage support This was working around a bug in ccache that was fixed in ccache 3.2.2 (released 2015-05-10). (Users of older ccache versions can continue to set CCACHE_DISABLE themselves.) Discussion: https://www.postgresql.org/message-id/20190530191130.GA24528@alvherre.pgsql Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/2e5c83acbb7b3916037b3e3a2f81ced10d413a3e Modified Files -- src/Makefile.global.in | 5 - 1 file changed, 5 deletions(-)
