-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
1ebf00c to 72bc1c1 #55
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Noted while comparing existing code to the output of the proposed patch to automate creation of these functions. Some of the changes are just cosmetic, but others represent real bugs. I've not attempted to analyze the user-visible impact. Back-patch to v15 where this code came in. Discussion: https://postgr.es/m/[email protected] (cherry picked from commit 8d9f9634ef21ab0023e2bd98e799f5ad2eec4539)
When we changed some built-in functions to use anycompatiblearray instead of anyarray, we created a dump/restore hazard for user-defined operators and aggregates relying on those functions: the user objects have to be modified to change their signatures similarly. This causes pg_upgrade to fail partway through if the source installation contains such objects. We generally try to have pg_upgrade detect such hazards and fail before it does anything exciting, so add logic to detect this case too. Back-patch to v14 where the change was made. Justin Pryzby, reviewed by Andrey Borodin Discussion: https://postgr.es/m/3383880.QJadu78ljV@vejsadalnx (cherry picked from commit 09878cdd489ff7aca761998e7cb104f4fd98ae02)
This is more consistent with how other predefined roles that confer specific privileges are named. Nathan Bosart Discussion: http://postgr.es/m/CA+TgmoatH7+yYe+A8uJFNogg3VUDtFE6c-77yHAY8TRWR7oqyw@mail.gmail.com (cherry picked from commit b9eb0ff09eb843566645679c3ab65b3c9d12c08b)
This reverts most of 91c0570, f28bf66, fe0972e, afdeff1. The only thing left is the retry loop in 019_replslot_limit.pl that avoids spurious failures by retrying a couple times. We haven't seen any hard evidence that this is caused by anything but slow process shutdown. We did not find any cases where walsenders did not vanish after waiting for longer. Therefore there's no reason for this debugging code to remain. Discussion: https://postgr.es/m/[email protected] Backpatch: 15- (cherry picked from commit 3f8148c256e067dc2e8929ed174671ba7dc3339c)
The new expression step types increased the size of ExprEvalStep by ~4 for all types of expression steps, slowing down expression evaluation noticeably. Move them out of line. There's other issues with these expression steps, but addressing them is largely independent of this aspect. Author: Andres Freund <[email protected]> Reviewed-By: Andrew Dunstan <[email protected]> Discussion: https://postgr.es/m/[email protected] Backpatch: 15- (cherry picked from commit 67b26703b4152a30a91208e28a4b72b3abda5832)
Previously the timer was enabled whenever there were any pending stats after executing a statement, just to then be disabled again when not idle anymore. That lead to an increase in GetCurrentTimestamp() calls from within timeout.c compared to 14. To avoid that increase, leave the timer enabled until stats are reported, rather than until idle. The timer is only disabled once the pending stats have been reported. For me this fixes the increase in GetCurrentTimestamp() calls, there now are fewer calls in 15 than in 14, in the previously slowed down workload. While at it, also update assertion in pgstat_report_stat() to be more precise. Author: Andres Freund <[email protected]> Discussion: https://postgr.es/m/[email protected] Backpatch: 15- (cherry picked from commit 056cc366fafa8110f5761a7383ae1cd903dd728c)
We only need to reject cases when the aggregate or operator is itself declared with a polymorphic type. Per buildfarm. Discussion: https://postgr.es/m/3383880.QJadu78ljV@vejsadalnx (cherry picked from commit 08385ed261965c4e1604e357330ac5bf9755b01a)
auto_explain.log_parameter_max_length is a new GUC part of the extension, similar to the corresponding core setting, that controls the inclusion of query parameters in the logged explain output. More tests are added to check the behavior of this new parameter: when parameters logged in full (the default of -1), when disabled (value of 0) and when partially truncated (value different than the two others). Author: Dagfinn Ilmari Mannsåker Discussion: https://postgr.es/m/[email protected] (cherry picked from commit d4bfe41281705c1bcb7093b3d07ce5ff1114341b)
This makes it easier to maintain the order if we automate the generation of this file. (cherry picked from commit 4b8ee4e9d37bb12969aeaf4225b001b11da6de0c)
macOS has traditionally used extension .dylib for shared libraries (used at build time) and .so for dynamically loaded modules (used by dlopen()). This complicates the build system a bit. Also, Meson uses .dylib for both, so it would be worth unifying this in order to be able to get equal build output. There doesn't appear to be any reason to use any particular extension for dlopened modules, since dlopen() will accept anything and PostgreSQL is well-factored to be able to deal with any extension. Other software packages that I have handy appear to be about 50/50 split on which extension they use for their plugins. So it seems possible to change this safely. Discussion: https://www.postgresql.org/message-id/flat/bcc45f78-e3c3-8fb3-7c42-5371b48b5266%40enterprisedb.com (cherry picked from commit b55f62abb2c2e07dfae99e19a2b3d7ca9e58dc1a)
Some routines open-coded the construction of DataRow messages. Use TupOutputState struct and associated functions instead, which was already done in some places. SendTimeLineHistory() is a bit more complicated and isn't converted by this. Reviewed-by: Nathan Bossart <[email protected]> Discussion: https://www.postgresql.org/message-id/flat/[email protected] (cherry picked from commit 16d52fc89dbe8394ed318521e076f08fd2e4bf8c)
50e17ad increased the size of ExprEvalStep from 64 bytes up to 88 bytes. Lots of effort was spent during the development of the current expression evaluation code to make an instance of this struct as small as possible. Making this struct larger than needed reduces CPU cache efficiency during expression evaluation which causes noticeable slowdowns during query execution. In order to reduce the size of the struct, here we remove the fn_addr field. The values from this field can be obtained via fcinfo, just with some extra pointer dereferencing. The extra indirection does not seem to cause any noticeable slowdowns. Various other fields have been moved into the ScalarArrayOpExprHashTable struct. These fields are only used when the ScalarArrayOpExprHashTable pointer has already been dereferenced, so no additional pointer dereferences occur for these. Here we also make hash_fcinfo_data the last field in ScalarArrayOpExprHashTable so that we can avoid a further pointer dereference to get the FunctionCallInfoBaseData. This also saves a call to palloc(). 50e17ad was added in 14, but it's too late to adjust the size of the ExprEvalStep in that version, so here we just backpatch to 15, which is currently in beta. Author: Andres Freund, David Rowley Discussion: https://postgr.es/m/[email protected] Backpatch-through: 15 (cherry picked from commit fe3caa1439378830d13423939b13e39d5afa8cf0)
This makes the output match that produced by meson (and also matches other packages and pkg-config's own documentation better). (cherry picked from commit eb7a9cd459736f29c5d091cf1bf59842ec9c7175)
LLVM_CONFIG is only used inside configure. Reviewed-By: Peter Eisentraut <[email protected]> Discussion: https://postgr.es/m/[email protected] (cherry picked from commit 7775c748db1257523ecbed1060dadb608bdff6de)
2jungkook
approved these changes
Nov 28, 2023
priyansx
approved these changes
Nov 28, 2023
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Cherry-pick of 14 community commits, no conflicts.
Extension PR: amazon-aurora/babelfish_extensions#54