pgsql: Remove unnecessary array object_classes[] in dependency.c
Remove unnecessary array object_classes[] in dependency.c object_classes[] provided unnecessary indirection between catalog OIDs and the enum ObjectClass when calling add_object_address(). This array has been originally introduced in 30ec31604d5 and was useful because not all relation OIDs were compile-time constants back then, which has not been the case for a long time now for all the elements of ObjectClass. This commit removes object_classes[], switching to the catalog OIDs when calling add_object_address(). This shaves some code while saving in maintenance because it was necessary to maintain the enum ObjectClass and the array in sync when adding new object types. Reported-by: Jeff Davis Author: Jelte Fennema-Nio Reviewed-by: Jian He, Michael Paquier Discussion: https://postgr.es/m/cageczqt3caubcccsznewccmmbcuyp7xnam60j3ybd6pn5kh...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/ef5e2e90859a39efdd3a78e528c544b585295a78 Modified Files -- src/backend/catalog/dependency.c | 181 ++- src/include/catalog/dependency.h | 4 +- 2 files changed, 63 insertions(+), 122 deletions(-)
pgsql: Adjust memory allocation functions to allow sibling calls
Adjust memory allocation functions to allow sibling calls Many modern compilers are able to optimize function calls to functions where the parameters of the called function match a leading subset of the calling function's parameters. If there are no instructions in the calling function after the function is called, then the compiler is free to avoid any stack frame setup and implement the function call as a "jmp" rather than a "call". This is called sibling call optimization. Here we adjust the memory allocation functions in mcxt.c to allow this optimization. This requires moving some responsibility into the memory context implementations themselves. It's now the responsibility of the MemoryContext to check for malloc failures. This is good as it both allows the sibling call optimization, but also because most small and medium allocations won't call malloc and just allocate memory to an existing block. That can't fail, so checking for NULLs in that case isn't required. Also, traditionally it's been the responsibility of palloc and the other allocation functions in mcxt.c to check for invalid allocation size requests. Here we also move the responsibility of checking that into the MemoryContext. This isn't to allow the sibling call optimization, but more because most of our allocators handle large allocations separately and we can just add the size check when doing large allocations. We no longer check this for non-large allocations at all. To make checking the allocation request sizes and ERROR handling easier, add some helper functions to mcxt.c for the allocators to use. Author: Andres Freund Reviewed-by: David Rowley Discussion: https://postgr.es/m/20210719195950.gavgs6ujzmjfa...@alap3.anarazel.de Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/743112a2e9938b98d716384fa9374c41afe74e41 Modified Files -- src/backend/utils/mmgr/alignedalloc.c | 11 +- src/backend/utils/mmgr/aset.c | 22 ++-- src/backend/utils/mmgr/generation.c | 17 +-- src/backend/utils/mmgr/mcxt.c | 229 ++ src/backend/utils/mmgr/slab.c | 11 +- src/include/nodes/memnodes.h | 42 ++- src/include/utils/memutils_internal.h | 30 +++-- 7 files changed, 196 insertions(+), 166 deletions(-)
pgsql: Fix comment thinko in sequence.c
Fix comment thinko in sequence.c One comment mentioned indexes, but the relation opened should be sequences. Reported-by: Matthias van de Meent Discussion: https://postgr.es/m/CAEze2WiMGNG9XK3NSUen-5BARhCnP=u=fxnf8pvpl2qdkeo...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/17a3f79f812cf196063c4146d64c6479e974a5c5 Modified Files -- src/backend/access/sequence/sequence.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Use NULL instead of 0 for 'arg' argument in dshash_create() call
Use NULL instead of 0 for 'arg' argument in dshash_create() calls. A couple of dshash_create() callers provide 0 for the 'void *arg' argument, which might give readers the incorrect impression that this is some sort of "flags" parameter. Reviewed-by: Andy Fan Discussion: https://postgr.es/m/20240119215941.GA1322079%40nathanxps13 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/5fe08c006c826da4a7f5db2a79327477599edbc6 Modified Files -- src/backend/replication/logical/launcher.c | 2 +- src/backend/utils/activity/pgstat_shmem.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
pgsql: Add helper functions for dshash tables with string keys.
Add helper functions for dshash tables with string keys. Presently, string keys are not well-supported for dshash tables. The dshash code always copies key_size bytes into new entries' keys, and dshash.h only provides compare and hash functions that forward to memcmp() and tag_hash(), both of which do not stop at the first NUL. This means that callers must pad string keys so that the data beyond the first NUL does not adversely affect the results of copying, comparing, and hashing the keys. To better support string keys in dshash tables, this commit does a couple things: * A new copy_function field is added to the dshash_parameters struct. This function pointer specifies how the key should be copied into new table entries. For example, we only want to copy up to the first NUL byte for string keys. A dshash_memcpy() helper function is provided and used for all existing in-tree dshash tables without string keys. * A set of helper functions for string keys are provided. These helper functions forward to strcmp(), strcpy(), and string_hash(), all of which ignore data beyond the first NUL. This commit also adjusts the DSM registry's dshash table to use the new helper functions for string keys. Reviewed-by: Andy Fan Discussion: https://postgr.es/m/20240119215941.GA1322079%40nathanxps13 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/42a1de3013eac394c3a170ce728f0280a62187bd Modified Files -- src/backend/lib/dshash.c | 58 +- src/backend/replication/logical/launcher.c | 1 + src/backend/storage/ipc/dsm_registry.c | 9 +++-- src/backend/utils/activity/pgstat_shmem.c | 1 + src/backend/utils/cache/typcache.c | 2 ++ src/include/lib/dshash.h | 19 +- 6 files changed, 83 insertions(+), 7 deletions(-)
pgsql: Revise MERGE documentation
Revise MERGE documentation Add a note about the additional privileges required after the fix in 4989ce72644b (wording per Tom Lane); also change marked-up mentions of "target_table_name" to be simply "the target table" or the like. Also, note that "join_condition" is scouted for requisite privileges. Backpatch to 15. Discussion: https://postgr.es/m/202402211653.zuh6objy3z72@alvherre.pgsql Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/6979ea2638a51c40acf6d04b816550b2c35b3e55 Modified Files -- doc/src/sgml/ref/merge.sgml | 50 +++-- 1 file changed, 26 insertions(+), 24 deletions(-)
pgsql: Revise MERGE documentation
Revise MERGE documentation Add a note about the additional privileges required after the fix in 4989ce72644b (wording per Tom Lane); also change marked-up mentions of "target_table_name" to be simply "the target table" or the like. Also, note that "join_condition" is scouted for requisite privileges. Backpatch to 15. Discussion: https://postgr.es/m/202402211653.zuh6objy3z72@alvherre.pgsql Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/172d7f7e666ee0612b7d56d7b73a7ebc98476a66 Modified Files -- doc/src/sgml/ref/merge.sgml | 50 +++-- 1 file changed, 26 insertions(+), 24 deletions(-)
pgsql: Revise MERGE documentation
Revise MERGE documentation Add a note about the additional privileges required after the fix in 4989ce72644b (wording per Tom Lane); also change marked-up mentions of "target_table_name" to be simply "the target table" or the like. Also, note that "join_condition" is scouted for requisite privileges. Backpatch to 15. Discussion: https://postgr.es/m/202402211653.zuh6objy3z72@alvherre.pgsql Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/c4bd6ff57c9a7b188cbd93855755f1029d7a5662 Modified Files -- doc/src/sgml/ref/merge.sgml | 50 +++-- 1 file changed, 26 insertions(+), 24 deletions(-)
pgsql: slru.c: Reduce scope of variables in 'for' blocks
slru.c: Reduce scope of variables in 'for' blocks Pretty boring. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/5f79cb7629a4ce6321f509694ebf475a931608b6 Modified Files -- src/backend/access/transam/slru.c | 33 +++-- 1 file changed, 11 insertions(+), 22 deletions(-)
pgsql: Group more closely cache updates for backends in sequence.c
Group more closely cache updates for backends in sequence.c Information of sequences is cached for each backend for currval() and nextval(), and the update of some cached information was mixed in the middle of computations based on the other properties of a sequence, for the increment value in nextval() and the cached state when altering a sequence. Grouping them makes the code easier to follow and to refactor in the future, when splitting the computation and the SeqTable change parts. Note that the cached data is untouched between the areas where these cache updates are moved. Issue noticed while doing some refactoring of the sequence code. Author: Michael Paquier Reviewed-by: Tomas Vondra Discussion: https://postgr.es/m/zwlohtkas0uvv...@paquier.xyz Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/6e951bf98e2e0230ed95db2fafc244536bd7502f Modified Files -- src/backend/commands/sequence.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-)