pgsql: Fix out-of-bound read in gtsvector_picksplit()
Fix out-of-bound read in gtsvector_picksplit() This could lead to an imprecise choice when splitting an index page of a GiST index on a tsvector, deciding which entries should remain on the old page and which entries should move to a new page. This is wrong since tsearch2 has been moved into core with commit 140d4ebcb46e, so backpatch all the way down. This error has been spotted by valgrind. Author: Alexander Lakhin Discussion: https://postgr.es/m/17950-6c80a8d2b94ec...@postgresql.org Backpatch-through: 11 Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/82fa8ae5f9ac4827dd29a6feaf53da931b5706d1 Modified Files -- src/backend/utils/adt/tsgistidx.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
pgsql: Fix out-of-bound read in gtsvector_picksplit()
Fix out-of-bound read in gtsvector_picksplit() This could lead to an imprecise choice when splitting an index page of a GiST index on a tsvector, deciding which entries should remain on the old page and which entries should move to a new page. This is wrong since tsearch2 has been moved into core with commit 140d4ebcb46e, so backpatch all the way down. This error has been spotted by valgrind. Author: Alexander Lakhin Discussion: https://postgr.es/m/17950-6c80a8d2b94ec...@postgresql.org Backpatch-through: 11 Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/88aa4a049acaaea4db2d7946154ae72110910f32 Modified Files -- src/backend/utils/adt/tsgistidx.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
pgsql: Fix out-of-bound read in gtsvector_picksplit()
Fix out-of-bound read in gtsvector_picksplit() This could lead to an imprecise choice when splitting an index page of a GiST index on a tsvector, deciding which entries should remain on the old page and which entries should move to a new page. This is wrong since tsearch2 has been moved into core with commit 140d4ebcb46e, so backpatch all the way down. This error has been spotted by valgrind. Author: Alexander Lakhin Discussion: https://postgr.es/m/17950-6c80a8d2b94ec...@postgresql.org Backpatch-through: 11 Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/fac3fa0d5b21ce59258a691b88e4176a06722bfc Modified Files -- src/backend/utils/adt/tsgistidx.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
pgsql: Fix out-of-bound read in gtsvector_picksplit()
Fix out-of-bound read in gtsvector_picksplit() This could lead to an imprecise choice when splitting an index page of a GiST index on a tsvector, deciding which entries should remain on the old page and which entries should move to a new page. This is wrong since tsearch2 has been moved into core with commit 140d4ebcb46e, so backpatch all the way down. This error has been spotted by valgrind. Author: Alexander Lakhin Discussion: https://postgr.es/m/17950-6c80a8d2b94ec...@postgresql.org Backpatch-through: 11 Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/df11421d8242dd13b2b734d7f2ff65aff7619b85 Modified Files -- src/backend/utils/adt/tsgistidx.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
pgsql: Fix out-of-bound read in gtsvector_picksplit()
Fix out-of-bound read in gtsvector_picksplit() This could lead to an imprecise choice when splitting an index page of a GiST index on a tsvector, deciding which entries should remain on the old page and which entries should move to a new page. This is wrong since tsearch2 has been moved into core with commit 140d4ebcb46e, so backpatch all the way down. This error has been spotted by valgrind. Author: Alexander Lakhin Discussion: https://postgr.es/m/17950-6c80a8d2b94ec...@postgresql.org Backpatch-through: 11 Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/358cd2b25109f50f2d3a9a29ed90fed9dc362df3 Modified Files -- src/backend/utils/adt/tsgistidx.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
pgsql: Fix out-of-bound read in gtsvector_picksplit()
Fix out-of-bound read in gtsvector_picksplit() This could lead to an imprecise choice when splitting an index page of a GiST index on a tsvector, deciding which entries should remain on the old page and which entries should move to a new page. This is wrong since tsearch2 has been moved into core with commit 140d4ebcb46e, so backpatch all the way down. This error has been spotted by valgrind. Author: Alexander Lakhin Discussion: https://postgr.es/m/17950-6c80a8d2b94ec...@postgresql.org Backpatch-through: 11 Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/40ddb8db9f2c62aed5025aaf503e188f7d1f27af Modified Files -- src/backend/utils/adt/tsgistidx.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
pgsql: Fix out-of-bound read in gtsvector_picksplit()
Fix out-of-bound read in gtsvector_picksplit() This could lead to an imprecise choice when splitting an index page of a GiST index on a tsvector, deciding which entries should remain on the old page and which entries should move to a new page. This is wrong since tsearch2 has been moved into core with commit 140d4ebcb46e, so backpatch all the way down. This error has been spotted by valgrind. Author: Alexander Lakhin Discussion: https://postgr.es/m/17950-6c80a8d2b94ec...@postgresql.org Backpatch-through: 11 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/ae10dbb0c5e09bff9e26412de7940271ef501164 Modified Files -- src/backend/utils/adt/tsgistidx.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
pgsql: Fix typo in decode.c.
Fix typo in decode.c. Author: Hou Zhijie Discussion: http://postgr.es/m/os0pr01mb57162dfffcfcda2e4b95899394...@os0pr01mb5716.jpnprd01.prod.outlook.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/e70ed4b1b87d22b47955c2bdee567ef8424e6df8 Modified Files -- src/backend/replication/logical/decode.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Fix handling of shared statistics with dropped databases
Fix handling of shared statistics with dropped databases Dropping a database while a connection is attempted on it was able to lead to the presence of valid database entries in shared statistics. The issue is that MyDatabaseId was getting set too early than it should, as, if the connection attempted on the dropped database fails when renamed or dropped, the shutdown callback of the shared statistics would finish by re-inserting a correct entry related to the database already dropped. As analyzed by the bug reporters, this issue could lead to phantom entries in the database list maintained by the autovacuum launcher (in rebuild_database_list()) if the database dropped was part of the database list when it was still valid. After the database was dropped, it would remain the highest on the list of databases to considered by the autovacuum worker as things to process. This would prevent autovacuum jobs to happen on all the other databases still present. The commit fixes this issue by delaying setting MyDatabaseId until the database existence has been re-checked with the second scan on pg_database after getting a shared lock on it, and by switching pgstat_update_dbstats() so as nothing happens if MyDatabaseId is not valid. Issue introduced by 5891c7a8ed8f, so backpatch down to 15. Reported-by: Will Mortensen, Jacob Speidel Analyzed-by: Will Mortensen, Jacob Speidel Author: Andres Freund Discussion: https://postgr.es/m/17973-bca1f7d5c14f6...@postgresql.org Backpatch-through: 15 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/2b8e5273e949003f299ddcae5f8c4b44c6eb9edc Modified Files -- src/backend/utils/activity/pgstat_database.c | 13 +++ src/backend/utils/init/postinit.c| 118 ++- 2 files changed, 74 insertions(+), 57 deletions(-)
pgsql: Fix handling of shared statistics with dropped databases
Fix handling of shared statistics with dropped databases Dropping a database while a connection is attempted on it was able to lead to the presence of valid database entries in shared statistics. The issue is that MyDatabaseId was getting set too early than it should, as, if the connection attempted on the dropped database fails when renamed or dropped, the shutdown callback of the shared statistics would finish by re-inserting a correct entry related to the database already dropped. As analyzed by the bug reporters, this issue could lead to phantom entries in the database list maintained by the autovacuum launcher (in rebuild_database_list()) if the database dropped was part of the database list when it was still valid. After the database was dropped, it would remain the highest on the list of databases to considered by the autovacuum worker as things to process. This would prevent autovacuum jobs to happen on all the other databases still present. The commit fixes this issue by delaying setting MyDatabaseId until the database existence has been re-checked with the second scan on pg_database after getting a shared lock on it, and by switching pgstat_update_dbstats() so as nothing happens if MyDatabaseId is not valid. Issue introduced by 5891c7a8ed8f, so backpatch down to 15. Reported-by: Will Mortensen, Jacob Speidel Analyzed-by: Will Mortensen, Jacob Speidel Author: Andres Freund Discussion: https://postgr.es/m/17973-bca1f7d5c14f6...@postgresql.org Backpatch-through: 15 Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/c397c98ae63d57c35766dbefe4ea34a5162abf53 Modified Files -- src/backend/utils/activity/pgstat_database.c | 13 +++ src/backend/utils/init/postinit.c| 118 ++- 2 files changed, 74 insertions(+), 57 deletions(-)
pgsql: Fix handling of shared statistics with dropped databases
Fix handling of shared statistics with dropped databases Dropping a database while a connection is attempted on it was able to lead to the presence of valid database entries in shared statistics. The issue is that MyDatabaseId was getting set too early than it should, as, if the connection attempted on the dropped database fails when renamed or dropped, the shutdown callback of the shared statistics would finish by re-inserting a correct entry related to the database already dropped. As analyzed by the bug reporters, this issue could lead to phantom entries in the database list maintained by the autovacuum launcher (in rebuild_database_list()) if the database dropped was part of the database list when it was still valid. After the database was dropped, it would remain the highest on the list of databases to considered by the autovacuum worker as things to process. This would prevent autovacuum jobs to happen on all the other databases still present. The commit fixes this issue by delaying setting MyDatabaseId until the database existence has been re-checked with the second scan on pg_database after getting a shared lock on it, and by switching pgstat_update_dbstats() so as nothing happens if MyDatabaseId is not valid. Issue introduced by 5891c7a8ed8f, so backpatch down to 15. Reported-by: Will Mortensen, Jacob Speidel Analyzed-by: Will Mortensen, Jacob Speidel Author: Andres Freund Discussion: https://postgr.es/m/17973-bca1f7d5c14f6...@postgresql.org Backpatch-through: 15 Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/5a9325fdde1d8ab8031fa09ebd0f63dc3f967a0a Modified Files -- src/backend/utils/activity/pgstat_database.c | 13 +++ src/backend/utils/init/postinit.c| 118 ++- 2 files changed, 74 insertions(+), 57 deletions(-)
