pgsql: Initialize ShmemVariableCache like other shmem areas
Initialize ShmemVariableCache like other shmem areas For sake of consistency. Reviewed-by: Tristan Partin, Richard Guo Discussion: https://www.postgresql.org/message-id/6537d63d-4bb5-46f8-9b5d-73a8ba472...@iki.fi Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/15916ffb0468d0b1036ba661767fe6e1b5fb3ee8 Modified Files -- src/backend/access/transam/varsup.c | 27 +++ src/backend/postmaster/postmaster.c | 4 src/backend/storage/ipc/ipci.c | 3 +++ src/backend/storage/ipc/shmem.c | 8 src/include/access/transam.h| 2 ++ 5 files changed, 32 insertions(+), 12 deletions(-)
pgsql: Rename ShmemVariableCache to TransamVariables
Rename ShmemVariableCache to TransamVariables The old name was misleading: It's not a cache, the values kept in the struct are the authoritative source. Reviewed-by: Tristan Partin, Richard Guo Discussion: https://www.postgresql.org/message-id/6537d63d-4bb5-46f8-9b5d-73a8ba472...@iki.fi Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/b31ba5310b5176402b60abc0454a033b1210ab75 Modified Files -- contrib/amcheck/verify_heapam.c | 14 +-- src/backend/access/transam/clog.c| 6 +- src/backend/access/transam/commit_ts.c | 44 +- src/backend/access/transam/subtrans.c| 4 +- src/backend/access/transam/twophase.c| 12 +-- src/backend/access/transam/varsup.c | 104 +++ src/backend/access/transam/xlog.c| 54 ++-- src/backend/access/transam/xlogreader.c | 4 +- src/backend/access/transam/xlogrecovery.c| 2 +- src/backend/postmaster/autovacuum.c | 4 +- src/backend/storage/ipc/procarray.c | 66 +++--- src/backend/storage/lmgr/predicate.c | 2 +- src/backend/utils/adt/xid8funcs.c| 10 +-- src/include/access/transam.h | 10 +-- src/include/storage/standby.h| 2 +- src/include/storage/standbydefs.h| 2 +- src/test/modules/xid_wraparound/xid_wraparound.c | 4 +- src/tools/pgindent/typedefs.list | 3 +- 18 files changed, 172 insertions(+), 175 deletions(-)
pgsql: Don't try to open visibilitymap when analyzing a foreign table
Don't try to open visibilitymap when analyzing a foreign table It's harmless, visibilitymap_count() returns 0 if the file doesn't exist. But it's also very pointless. I noticed this when I added an assertion in smgropen() that the relnumber is valid. Discussion: https://www.postgresql.org/message-id/621a52fd-3cd8-4f5d-a561-d510b853b...@iki.fi Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/049ef3398d05c9dc8f48aa9a6d68440661cfeb87 Modified Files -- src/backend/commands/analyze.c | 5 - src/backend/storage/smgr/smgr.c | 2 ++ 2 files changed, 6 insertions(+), 1 deletion(-)
pgsql: Fix potential pointer overflow in xlogreader.c.
Fix potential pointer overflow in xlogreader.c. While checking if a record could fit in the circular WAL decoding buffer, the coding from commit 3f1ce973 used arithmetic that could overflow. 64 bit systems were unaffected for various technical reasons, which probably explains the lack of problem reports. Likewise for 32 bit systems running known 32 bit kernels. The systems at risk of problems appear to be 32 bit processes running on 64 bit kernels, with unlucky placement in memory. Per complaint from GCC -fsanitize=undefined -m32, while testing variations of 039_end_of_wal.pl. Back-patch to 15. Reviewed-by: Nathan Bossart Reviewed-by: Robert Haas Discussion: https://postgr.es/m/CA%2BhUKGKH0oRPOX7DhiQ_b51sM8HqcPp2J3WA-Oen%3DdXog%2BAGGQ%40mail.gmail.com Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/b9f687f5abaf40c13fed59fe08014116a8344102 Modified Files -- src/backend/access/transam/xlogreader.c | 46 ++--- 1 file changed, 37 insertions(+), 9 deletions(-)
pgsql: Fix potential pointer overflow in xlogreader.c.
Fix potential pointer overflow in xlogreader.c. While checking if a record could fit in the circular WAL decoding buffer, the coding from commit 3f1ce973 used arithmetic that could overflow. 64 bit systems were unaffected for various technical reasons, which probably explains the lack of problem reports. Likewise for 32 bit systems running known 32 bit kernels. The systems at risk of problems appear to be 32 bit processes running on 64 bit kernels, with unlucky placement in memory. Per complaint from GCC -fsanitize=undefined -m32, while testing variations of 039_end_of_wal.pl. Back-patch to 15. Reviewed-by: Nathan Bossart Reviewed-by: Robert Haas Discussion: https://postgr.es/m/CA%2BhUKGKH0oRPOX7DhiQ_b51sM8HqcPp2J3WA-Oen%3DdXog%2BAGGQ%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/cd7f19da34684b7b12fdc08511c5ce7bebb09419 Modified Files -- src/backend/access/transam/xlogreader.c | 46 ++--- 1 file changed, 37 insertions(+), 9 deletions(-)
pgsql: Fix potential pointer overflow in xlogreader.c.
Fix potential pointer overflow in xlogreader.c. While checking if a record could fit in the circular WAL decoding buffer, the coding from commit 3f1ce973 used arithmetic that could overflow. 64 bit systems were unaffected for various technical reasons, which probably explains the lack of problem reports. Likewise for 32 bit systems running known 32 bit kernels. The systems at risk of problems appear to be 32 bit processes running on 64 bit kernels, with unlucky placement in memory. Per complaint from GCC -fsanitize=undefined -m32, while testing variations of 039_end_of_wal.pl. Back-patch to 15. Reviewed-by: Nathan Bossart Reviewed-by: Robert Haas Discussion: https://postgr.es/m/CA%2BhUKGKH0oRPOX7DhiQ_b51sM8HqcPp2J3WA-Oen%3DdXog%2BAGGQ%40mail.gmail.com Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/8ca56620caffd6a1761eebd6a9498235321f222b Modified Files -- src/backend/access/transam/xlogreader.c | 46 ++--- 1 file changed, 37 insertions(+), 9 deletions(-)
pgsql: doc: clarify handling of ON CONFLICT with triggers
doc: clarify handling of ON CONFLICT with triggers The previous wording was confusing. Also move partitioning mention to a more logical location. Reported-by: n...@fairwindsoft.com Discussion: https://postgr.es/m/20170703200710.27956.64...@wrigleys.postgresql.org Backpatch-through: master Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/2cc2d02dd04ff01602f25c141d814ab46776ade4 Modified Files -- doc/src/sgml/trigger.sgml | 38 ++ 1 file changed, 18 insertions(+), 20 deletions(-)
pgsql: Fix path of regress shared library in pg_upgrade test
Fix path of regress shared library in pg_upgrade test During a pg_upgrade test using an old dump, all references to the old regress shared library path (so, dylib or dll) are updated to point to the library path used by the new build, to ensure a consistent comparison between the old and new dumps. The test previously relied on a hardcoded value of "src/test/regress/" to build the new path value, which would point to an incorrect location for the meson and vpath builds. This is replaced by REGRESS_SHLIB, able to point to the correct location of the regress shared library. Author: Alexander Lakhin Discussion: https://postgr.es/m/a628d8ad-a08a-2eab-4ca9-641bc82d3...@gmail.com Backpatch-through: 15 Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/a09aa18eaa6aafd33bae7c32d99eb9e86a6ca3d6 Modified Files -- src/bin/pg_upgrade/t/002_pg_upgrade.pl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Fix path of regress shared library in pg_upgrade test
Fix path of regress shared library in pg_upgrade test During a pg_upgrade test using an old dump, all references to the old regress shared library path (so, dylib or dll) are updated to point to the library path used by the new build, to ensure a consistent comparison between the old and new dumps. The test previously relied on a hardcoded value of "src/test/regress/" to build the new path value, which would point to an incorrect location for the meson and vpath builds. This is replaced by REGRESS_SHLIB, able to point to the correct location of the regress shared library. Author: Alexander Lakhin Discussion: https://postgr.es/m/a628d8ad-a08a-2eab-4ca9-641bc82d3...@gmail.com Backpatch-through: 15 Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/24482838c2c4bf251896e7ace837d48ba1fdc036 Modified Files -- src/bin/pg_upgrade/t/002_pg_upgrade.pl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Fix path of regress shared library in pg_upgrade test
Fix path of regress shared library in pg_upgrade test During a pg_upgrade test using an old dump, all references to the old regress shared library path (so, dylib or dll) are updated to point to the library path used by the new build, to ensure a consistent comparison between the old and new dumps. The test previously relied on a hardcoded value of "src/test/regress/" to build the new path value, which would point to an incorrect location for the meson and vpath builds. This is replaced by REGRESS_SHLIB, able to point to the correct location of the regress shared library. Author: Alexander Lakhin Discussion: https://postgr.es/m/a628d8ad-a08a-2eab-4ca9-641bc82d3...@gmail.com Backpatch-through: 15 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/e5b8c4f68fa554b1db9951af579c70c2a4692e55 Modified Files -- src/bin/pg_upgrade/t/002_pg_upgrade.pl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: doc, pg_upgrade: add vacuumdb w/ tips for generating quick stats
doc, pg_upgrade: add vacuumdb w/ tips for generating quick stats Reported-by: Magnus Hagander Discussion: https://postgr.es/m/cabuevewgby-w7ektbjmy1rc+mmrl3fmrnx6yaukcr+7o9ps...@mail.gmail.com Backpatch-through: master Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/c0fcf077708c99d64c86087eb567999cb85848e0 Modified Files -- doc/src/sgml/ref/pgupgrade.sgml | 11 +++ 1 file changed, 11 insertions(+)
pgsql: doc: FOR UPDATE / KEY / SHARE / KEY SHARE takes an table alias
doc: FOR UPDATE / KEY / SHARE / KEY SHARE takes an table alias Previously only a table name was documented for this SELECT clause. Reported-by: robert Discussion: https://postgr.es/m/152483686904.19805.3369061025704720...@wrigleys.postgresql.org Backpatch-through: master Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/5134e9d295f335b4ee9f8846f934e5593f65e881 Modified Files -- doc/src/sgml/ref/select.sgml | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-)
pgsql: doc, intagg: fix one-to-many mention to many-to-many
doc, intagg: fix one-to-many mention to many-to-many Reported-by: Christophe Courtois Discussion: https://postgr.es/m/aa7cfd73-0d8d-596a-b684-39faa479a...@dalibo.com Author: Christophe Courtois Backpatch-through: master Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/651030a3d7b44e0f448f860f61b0eff26ac6 Modified Files -- doc/src/sgml/intagg.sgml | 42 +++--- 1 file changed, 23 insertions(+), 19 deletions(-)
pgsql: Shrink Unicode category table.
Shrink Unicode category table. Missing entries can implicitly be considered "unassigned". Discussion: https://postgr.es/m/ff4c2f2f9c8fc7ca27c1c24ae37ecaeaeaff6b53.ca...@j-davis.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/719b342d36ce9a049137817e93e6a18a711a40e4 Modified Files -- .../unicode/generate-unicode_category_table.pl | 21 +- src/common/unicode_category.c | 6 +- src/include/common/unicode_category_table.h| 711 + 3 files changed, 15 insertions(+), 723 deletions(-)
pgsql: Verify that attribute counts match in ExecCopySlot
Verify that attribute counts match in ExecCopySlot tts_virtual_copyslot() contained an Assert that checked that the srcslot contained <= attributes than the dstslot. This seems to be backwards as if the srcslot contained fewer attributes then the dstslot could be left with stale Datum values from the previously stored tuple. It might make more sense to allow the source to contain additional attributes and only copy the leading ones that also exist in the destination, however, that's not what we're doing here. Here we just remove the Assert from tts_virtual_copyslot() and add an Assert to ExecCopySlot() to verify the attribute counts match. There does not seem to be any places where the destination contains fewer attributes, so instead of going to the trouble of making the code properly handle this, let's just ensure the attribute counts match. If this Assert fails then that will indicate that we do have cases that require us to handle the srcslot with more attributes than the dstslot. It seems better to only write this code if there's a genuine requirement for it rather than write it now only to leave it untested. Thanks to Andres Freund for helping with the analysis of this. Discussion: https://postgr.es/m/caaphdvpmavbl0t+trorquyx1iqfqkmvtxtqnocow0pa2uh1...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/d16a0c1e2e3874cd5adfa9ee968008b6c4b1ae01 Modified Files -- src/backend/executor/execTuples.c | 2 -- src/include/executor/tuptable.h | 10 +- 2 files changed, 9 insertions(+), 3 deletions(-)
