pgsql: Correct heap vacuum boundary state setup ordering
Correct heap vacuum boundary state setup ordering 052026c9b9 mistakenly reordered setup steps in heap_vacuum_rel(), incorrectly moving RelationGetNumberOfBlocks() before vacuum_get_cutoffs(). OldestXmin must be determined before RelationGetNumberOfBlocks() calculates the number of blocks in the relation that will be vacuumed. Otherwise tuples older than OldestXmin may be inserted into the end of the relation into blocks that are not vacuumed. If additional tuples newer than those inserted into unscanned blocks but older than OldestXmin are inserted into free space earlier in the relation, the result could be advancing pg_class.relfrozenxid to a newer value than an unfrozen XID in one of the unscanned heap pages. Assigning an incorrect relfrozenxid can lead to data loss, so it is imperative that it correctly reflect the oldest unfrozen xid. Reported-by: Peter Geoghegan Author: Melanie Plageman Reviewed-by: Peter Geoghegan Discussion: https://postgr.es/m/CAH2-WzntqvVEdbbpqG5JqSZGuLWmy4PBfUO-OswfivKchr2gvw%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/31a7e175fd8f6079555f2bba95c7cc118236bb20 Modified Files -- src/backend/access/heap/vacuumlazy.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
pgsql: Disallow "=" in names of reloptions and foreign-data options.
Disallow "=" in names of reloptions and foreign-data options. We store values for these options as array elements with the syntax "name=value", hence a name containing "=" confuses matters when it's time to read the array back in. Since validation of the options is often done (long) after this conversion to array format, that leads to confusing and off-point error messages. We can improve matters by rejecting names containing "=" up-front. (Probably a better design would have involved pairs of array elements, but it's too late now --- and anyway, there's no evident use-case for option names like this. We already reject such names in some other contexts such as GUCs.) Reported-by: Chapman Flack Author: Tom Lane Reviewed-by: Chapman Flack Discussion: https://postgr.es/m/6830eb30.8090...@acm.org Backpatch-through: 13 Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/d4046125dd7d876b4930b346c28c588e622667ec Modified Files -- contrib/file_fdw/expected/file_fdw.out | 4 contrib/file_fdw/sql/file_fdw.sql | 2 ++ src/backend/access/common/reloptions.c | 17 + src/backend/commands/foreigncmds.c | 15 +-- 4 files changed, 32 insertions(+), 6 deletions(-)
pgsql: Disallow "=" in names of reloptions and foreign-data options.
Disallow "=" in names of reloptions and foreign-data options. We store values for these options as array elements with the syntax "name=value", hence a name containing "=" confuses matters when it's time to read the array back in. Since validation of the options is often done (long) after this conversion to array format, that leads to confusing and off-point error messages. We can improve matters by rejecting names containing "=" up-front. (Probably a better design would have involved pairs of array elements, but it's too late now --- and anyway, there's no evident use-case for option names like this. We already reject such names in some other contexts such as GUCs.) Reported-by: Chapman Flack Author: Tom Lane Reviewed-by: Chapman Flack Discussion: https://postgr.es/m/6830eb30.8090...@acm.org Backpatch-through: 13 Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/cd31eaaebc406d043f5dc240f8849d640490e707 Modified Files -- contrib/file_fdw/input/file_fdw.source | 2 ++ contrib/file_fdw/output/file_fdw.source | 5 + src/backend/access/common/reloptions.c | 17 + src/backend/commands/foreigncmds.c | 15 +-- 4 files changed, 33 insertions(+), 6 deletions(-)
pgsql: Disallow "=" in names of reloptions and foreign-data options.
Disallow "=" in names of reloptions and foreign-data options. We store values for these options as array elements with the syntax "name=value", hence a name containing "=" confuses matters when it's time to read the array back in. Since validation of the options is often done (long) after this conversion to array format, that leads to confusing and off-point error messages. We can improve matters by rejecting names containing "=" up-front. (Probably a better design would have involved pairs of array elements, but it's too late now --- and anyway, there's no evident use-case for option names like this. We already reject such names in some other contexts such as GUCs.) Reported-by: Chapman Flack Author: Tom Lane Reviewed-by: Chapman Flack Discussion: https://postgr.es/m/6830eb30.8090...@acm.org Backpatch-through: 13 Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/eb423464753f5a853ec47209aab05f74fafa9328 Modified Files -- contrib/file_fdw/input/file_fdw.source | 2 ++ contrib/file_fdw/output/file_fdw.source | 5 + src/backend/access/common/reloptions.c | 17 + src/backend/commands/foreigncmds.c | 15 +-- 4 files changed, 33 insertions(+), 6 deletions(-)
pgsql: Disallow "=" in names of reloptions and foreign-data options.
Disallow "=" in names of reloptions and foreign-data options. We store values for these options as array elements with the syntax "name=value", hence a name containing "=" confuses matters when it's time to read the array back in. Since validation of the options is often done (long) after this conversion to array format, that leads to confusing and off-point error messages. We can improve matters by rejecting names containing "=" up-front. (Probably a better design would have involved pairs of array elements, but it's too late now --- and anyway, there's no evident use-case for option names like this. We already reject such names in some other contexts such as GUCs.) Reported-by: Chapman Flack Author: Tom Lane Reviewed-by: Chapman Flack Discussion: https://postgr.es/m/6830eb30.8090...@acm.org Backpatch-through: 13 Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/ab758ec4d30745427e46b51b7b19b3c5483d513d Modified Files -- contrib/file_fdw/expected/file_fdw.out | 4 contrib/file_fdw/sql/file_fdw.sql | 2 ++ src/backend/access/common/reloptions.c | 17 + src/backend/commands/foreigncmds.c | 15 +-- 4 files changed, 32 insertions(+), 6 deletions(-)
pgsql: Disallow "=" in names of reloptions and foreign-data options.
Disallow "=" in names of reloptions and foreign-data options. We store values for these options as array elements with the syntax "name=value", hence a name containing "=" confuses matters when it's time to read the array back in. Since validation of the options is often done (long) after this conversion to array format, that leads to confusing and off-point error messages. We can improve matters by rejecting names containing "=" up-front. (Probably a better design would have involved pairs of array elements, but it's too late now --- and anyway, there's no evident use-case for option names like this. We already reject such names in some other contexts such as GUCs.) Reported-by: Chapman Flack Author: Tom Lane Reviewed-by: Chapman Flack Discussion: https://postgr.es/m/6830eb30.8090...@acm.org Backpatch-through: 13 Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/e76097124f7d6679d287701ab108aa20088b13a6 Modified Files -- contrib/file_fdw/expected/file_fdw.out | 5 + contrib/file_fdw/sql/file_fdw.sql | 2 ++ src/backend/access/common/reloptions.c | 17 + src/backend/commands/foreigncmds.c | 15 +-- 4 files changed, 33 insertions(+), 6 deletions(-)
pgsql: Rename log_lock_failure GUC to log_lock_failures for consistency
Rename log_lock_failure GUC to log_lock_failures for consistency. This commit renames the GUC log_lock_failure to log_lock_failures to align with the existing similar setting log_lock_waits, which uses the plural form. This improves naming consistency across related GUCs. Suggested-by: Peter Eisentraut Author: Fujii Masao Discussion: https://postgr.es/m/7a8198b6-d5b8-4910-b41e-8d3efcbb0...@eisentraut.org Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/73bdcfab35ec0a7eff1a5dd630cbad8e77054547 Modified Files -- doc/src/sgml/config.sgml | 6 +++--- doc/src/sgml/release-18.sgml | 2 +- src/backend/access/heap/heapam.c | 6 +++--- src/backend/access/heap/heapam_handler.c | 2 +- src/backend/storage/lmgr/lock.c | 2 +- src/backend/utils/misc/guc_tables.c | 4 ++-- src/backend/utils/misc/postgresql.conf.sample | 2 +- src/include/storage/lock.h| 2 +- 8 files changed, 13 insertions(+), 13 deletions(-)
pgsql: Disallow "=" in names of reloptions and foreign-data options.
Disallow "=" in names of reloptions and foreign-data options. We store values for these options as array elements with the syntax "name=value", hence a name containing "=" confuses matters when it's time to read the array back in. Since validation of the options is often done (long) after this conversion to array format, that leads to confusing and off-point error messages. We can improve matters by rejecting names containing "=" up-front. (Probably a better design would have involved pairs of array elements, but it's too late now --- and anyway, there's no evident use-case for option names like this. We already reject such names in some other contexts such as GUCs.) Reported-by: Chapman Flack Author: Tom Lane Reviewed-by: Chapman Flack Discussion: https://postgr.es/m/6830eb30.8090...@acm.org Backpatch-through: 13 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/aa87f69c009a062685f0c984dbcc18e60c02920d Modified Files -- contrib/file_fdw/expected/file_fdw.out | 4 contrib/file_fdw/sql/file_fdw.sql | 2 ++ src/backend/access/common/reloptions.c | 17 + src/backend/commands/foreigncmds.c | 15 +-- 4 files changed, 32 insertions(+), 6 deletions(-)
pgsql: Fix incorrect format placeholders
Fix incorrect format placeholders Fixes for return type of dclist_count(). Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/fc32be3c941f9d98dd9f549153a5fcea6c3e9b8b Modified Files -- src/backend/storage/aio/aio.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-)
