-
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
b0a55e43299c4ea2a9a8c757f9c26352407d0ccc..2373fe78dfc9d4aa2348a86fffdf8eb9d757e9d5 #57
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
There's no reason anymore to only drop subscription stats if associated with a slot, now that stats drops are transactional. And since there's now no other cleanup of stats, this would lead to stats for slot-less subscriptions to get leaked (however most slot-less subs won't have stats). Additionally, the comment referring to autovacuum cleaning up stats was clearly outdated. Author: Masahiko Sawada <[email protected]> Discussion: https://postgr.es/m/CAD21AoAwiby3HeJE7vJe16Gr75RFfJ640dyHqvsiUhyKJTXPtw@mail.gmail.com Backpatch: 15- (cherry picked from commit 7b64e4b3fa04769b725306a75bf3dd26e5a854fa)
It's not very robust to assume that each inserted row will produce exactly one WAL record and that no other WAL records will be generated in the process, because for example a particular transaction could always be the one that has to extend clog. Because these tests are not run by 'make installcheck' but only by 'make check', it may be that in our current testing infrastructure this can't be hit, but it doesn't seem like a good idea to rely on that, since unrelated changes to the regression tests or the way write-ahead logging is done could easily cause it to start happening, and debugging such failures is a pain. Adjust the regression test to be less sensitive. Anton Melnikov, reviewed by Julien Rouhaud Discussion: http://postgr.es/m/[email protected] (cherry picked from commit 2d7ead85267cc0a41ea4e94ee0ac144d5214d353)
40af10b changed things so we make use of a generation memory context for storing tuples to be sorted by tuplesort.c. That change does not play nicely with the changes made in 9f03ca9 (back in 2014). That commit changed things so that index_form_tuple() is called while switched into the tuplestore's tuplecontext. In order to fetch the tuple from the index, index_form_tuple() must do various memory allocations which are unrelated to the storage of the final returned tuple. Although all of these allocations are pfree'd, the fact that we now use a generation context means that the memory for these pfree'd allocations won't be used again by any other allocation due to generation.c's lack of freelists. This could result in sorts used for building indexes exceeding maintenance_work_mem by a very large amount. Here we fix it so we no longer allocate anything apart from the tuple itself into the generation context by adding a new version of index_form_tuple named index_form_tuple_context, which can be called to specify the MemoryContext to allocate the tuple into. Discussion: https://postgr.es/m/CAApHDvrHQkiFRHiGiAS-LMOvJN-eK-s762=tVzBz8ZqUea-a_A@mail.gmail.com Backpatch-through: 15, where 40af10b was added. (cherry picked from commit 0229106afab93e9868e758f4b555daafcfac4b75)
We hadn't noticed this because it's dead code: there is no situation where we read raw parse trees from text format. So maybe the right fix is to remove the function altogether, but I'll forbear for now; it's not the only dead code in readfuncs.c, I think. Noted while comparing existing code to the results of Peter's auto-generation script. (cherry picked from commit 55b8ac81723c45dca95d4ad4892a1ee28db37c23)
That comment might have been true at some point during development, but definitely isn't anymore. Reported-By: Melanie Plageman <[email protected]> Backpatch: 15- (cherry picked from commit f4d3ca421d9c67d55e527f74dde515d7f87996de)
A few tests included File::Path::rmtree without using it, and a comment related to the segment size for replication slot limits was wrong. Author: Pavel Borisov, Bharath Rupireddy Reviewed-by: Maxim Orlov Discussion: https://postgr.es/m/CALj2ACU4-aNLX=DrUM8F7QDwynJKzYRiqOj_33NhnGbhDs5-kQ@mail.gmail.com (cherry picked from commit 1409eade9f206baebbe9ed7e18cc9ef2979c6594)
By convention, the tab-complete subscription parameters are listed in the COMPLETE_WITH lists in alphabetical order, but when the "disable_on_error" parameter was introduced this was not done. This patch just tidies that up. Reported-by: Peter Smith Author: Peter Smith Reviewed-by: Euler Taveira, Takamichi Osumi Backpatch-through: 15, where it was introduced Discussion: https://postgr.es/m/CAHut+PucvKZgg_eJzUW--iL6DXHg1Jwj6F09tQziE3kUF67uLg@mail.gmail.com (cherry picked from commit d547f7cf5efc531be8587641a5682cc46b37bc81)
This commit bumps the runtime value of _WIN32_WINNT to be 0x0A00 for any builds on Windows. Hence, this makes Windows 10 the minimal requirement when running PostgreSQL under WIN32, be it for builds of Cygwin, MinGW or Visual Studio. The previous minimal runtime version was either Windows Vista when building with at least Visual Studio 2015 or Windows XP for the rest. Windows 10 is the most modern version supported by Microsoft, and per discussion, as we don't have buildfarm members that run older versions anymore, this is the minimal supported version that suits better for our needs. This will actually make easier the development of some patches, two being async I/O and large page handling by avoiding a lot of compatibility gotchas, on platforms that have most likely few users anyway. It is possible to remove MIN_WINNT in win32.h and the macros IsWindowsXXXOrGreater() that were used in the code at runtime to check which version of Windows was getting used. The change in pg_locale.c comes from Juan. Note that all my tests passed, and that the CI is green. The buildfarm will quickly tell if this needs more adjustments. Author: Michael Paquier, Juan José Santamaría Flecha Reviewed-by: Thomas Munro Discussion: https://postgr.es/m/[email protected] (cherry picked from commit 495ed0ef2d72a6a74def296e042022479d5d07bd)
Remove BlockIdIsValid(), which wasn't used and is unnecessary. Remove BlockIdCopy(), which wasn't used and can be done by struct assignment. (BlockIdEquals() also isn't used, but seems reasonable to keep around.) Reviewed-by: Amul Sul <[email protected]> Discussion: https://www.postgresql.org/message-id/flat/5b558da8-99fb-0a99-83dd-f72f05388517%40enterprisedb.com (cherry picked from commit d63d957e330c611f7a8c0ed02e4407f40f975026)
Oversight in commit 4036bcb; back-patch to v15 where that appeared. (cherry picked from commit 82699edbfe75534b3b6f6f4321339a432b7b8ff2)
When locking a specific named relation for a FOR [KEY] UPDATE/SHARE clause, transformLockingClause() finds the relation to lock by scanning the rangetable for an RTE with a matching eref->aliasname. However, it failed to account for the visibility rules of a join RTE. If a join RTE doesn't have a user-supplied alias, it will have a generated eref->aliasname of "unnamed_join" that is not visible as a relation name in the parse namespace. Such an RTE needs to be skipped, otherwise it might be found in preference to a regular base relation with a user-supplied alias of "unnamed_join", preventing it from being locked. In addition, if a join RTE doesn't have a user-supplied alias, but does have a join_using_alias, then the RTE needs to be matched using that alias rather than the generated eref->aliasname, otherwise a misleading "relation not found" error will be reported rather than a "join cannot be locked" error. Backpatch all the way, except for the second part which only goes back to 14, where JOIN USING aliases were added. Dean Rasheed, reviewed by Tom Lane. Discussion: https://postgr.es/m/CAEZATCUY_KOBnqxbTSPf=7fz9HWPnZ5Xgb9SwYzZ8rFXe7nb=w@mail.gmail.com (cherry picked from commit 8d367a44d34bbcaca4a894db2b3de741795141b7)
It is useful for debugging purposes to report the checkpoint LSN and REDO LSN in log_checkpoints message. It can give more context while analyzing checkpoint-related issues. pg_controldata reports the last checkpoint LSN and REDO LSN, but having this information alongside the log message helps analyze issues that happened previously, connect the dots and identify the root cause. Author: Bharath Rupireddy, Kyotaro Horiguchi Reviewed-by: Michael Paquier, Julien Rouhaud, Nathan Bossart, Fujii Masao, Greg Stark Discussion: https://postgr.es/m/CALj2ACWt6kqriAHrO+AJj+OmP=suwbktHT5JoYAn-nqZe2gd2g@mail.gmail.com (cherry picked from commit 62c46eee2279eb0300ab7ffe393d0d0dcfafb157)
The general convention in the executor is to refer to child plans and planstates via the outerPlan[State] and innerPlan[State] macros, but a few places didn't do it like that. For consistency and readability, convert all the stragglers to use the macros. (See also commit 40f42d2, which did some similar cleanup a few years ago, but missed these cases.) Richard Guo Discussion: https://postgr.es/m/CAMbWs4-vYhh1xsa_veah4PUed2Xq=Ed_YH3=Mqt5A3Y=EgfCEg@mail.gmail.com (cherry picked from commit 88210542106de5b26fe6aa088d1811b68502d224)
These are documented to be the allowed types for the RETURNING clause, but the restriction was not being enforced, which caused a segfault if another type was specified. Add some testing for this. Per report from a.kozhemyakin Backpatch to release 15. (cherry picked from commit 3c633f32b9c712cc0b4c8d946f0eeae04a3ff51a)
HP-UX hardware is no longer produced, build farm coverage recently ended, and there are no known active maintainers targeting this OS. Since there is a major rewrite of the build system in the pipeline for PostgreSQL 16, and that requires development, testing and maintainance for each OS and tool chain, it seems like a good time to drop support for: * HP-UX, the operating system. * HP aCC, the HP-UX native compiler. Reviewed-by: Tom Lane <[email protected]> Reviewed-by: Andres Freund <[email protected]> Reviewed-by: Peter Eisentraut <[email protected]> Discussion: https://postgr.es/m/1415825.1656893299%40sss.pgh.pa.us (cherry picked from commit 9db300ce6e38411144f1e36dba345a5f91bbdee4)
This CPU architecture has been discontinued. We already removed HP-UX support, we never supported Windows/Itanium, and the open source operating systems that a vintage hardware owner might hope to run have all either ended Itanium support or never fully released support (NetBSD may eventually). The extra code we carry for this rare ISA is now untested. It seems like a good time to remove it. Reviewed-by: Tom Lane <[email protected]> Reviewed-by: Andres Freund <[email protected]> Discussion: https://postgr.es/m/1415825.1656893299%40sss.pgh.pa.us (cherry picked from commit 0ad5b48e58945e88b71eb5932d0c003a95def6ea)
Reformat some more comments in node field definitions to avoid long lines. Similar to 835d476fd21bcfb60b055941dee8c3d9559af14c, based on additional per-field annotations that will be required. Discussion: https://www.postgresql.org/message-id/[email protected] (cherry picked from commit 3140f089855c03035ee354aa115618068f8d0206)
Instead of updating the length as we go, use a const pointer to end of the input, which we know already at the start. This simplifies the coding and may improve performance slightly, but the real motivation for doing this is to make further changes in this area easier to reason about. Discussion: https://www.postgresql.org/message-id/CAFBsxsGhaR2KQ5eisaK%3D6Vm60t%3DaxhD8Ckj1qFoCH1pktZi%2B2w%40mail.gmail.com (cherry picked from commit 3de359f18f2bfbc96272bd265264aa5c2f247ca4)
These are abstract node types that don't need to have a node tag defined. Discussion: https://www.postgresql.org/message-id/2592455.1657140387%40sss.pgh.pa.us (cherry picked from commit 251154bebe98ca5d3487ccbe0dceb7f412b57934)
Changed from AEXPR to A_EXPR for consistency. Discussion: https://www.postgresql.org/message-id/2592455.1657140387%40sss.pgh.pa.us (cherry picked from commit bf1f4a364d6c72cc5c39a6d81d156a0335fdf332)
Commit 9a974cb did this for user tables, but pg_upgrade treats pg_largeobject as a user table, and so needs the same treatment. Without this fix, if you rewrite the pg_largeobject table and then perform an upgrade with pg_upgrade, the table will apparently be empty on the new cluster, while all of your objects will end up with an orphaned file. With this fix, instead of the old cluster's pg_largeobject files ending up orphaned, the original files fro the new cluster do. That's mostly harmless because we expect the table to be empty, but we might want to arrange to remove the as part of the upgrade. Since we're still debating the best way of doing that, I (rhaas) have decided to postpone dealing with that problem and get the basic fix committed. Justin Pryzby, reviewed by Shruthi Gowda and by me. Discussion: http://postgr.es/m/[email protected] (cherry picked from commit d498e052b4b84ae21b3b68d5b3fda6ead65d1d4d)
This change should improve the code readability. Discussion: https://postgr.es/m/CAGRrpzYE8-7GCoaPjOiL9T_HY605MRax-2jgTtLq236uksZ1Sw%40mail.gmail.com Author: Steve Chavez, Alexander Korotkov Reviewed-by: Alexander Korotkov (cherry picked from commit 8d51d7f403c209ab4d5db203f5e350f6c71233ca)
PostgreSQL contains the implementation of the red-black tree. The red-black tree is the ordered data structure, and one of its advantages is the ability to do inequality searches. This commit adds rbt_find_less() and rbt_find_great() functions implementing these searches. While these searches aren't yet used in the core code, they might be useful for extensions. Discussion: https://postgr.es/m/CAGRrpzYE8-7GCoaPjOiL9T_HY605MRax-2jgTtLq236uksZ1Sw%40mail.gmail.com Author: Steve Chavez, Alexander Korotkov Reviewed-by: Alexander Korotkov (cherry picked from commit e57519a4637a8d88ae993ac1273d2b59d03a0f75)
Discussion: https://postgr.es/m/20220618085541.ezxdaljlpo6x7msc@home-desktop Author: Dong Wook Lee Backpatch-through: 11 (cherry picked from commit aa31b29375b9afbe1330d7726855645ff82a2e51)
The examples show the output of array_length() and jsonb_array_length() for empty arrays. Discussion: https://postgr.es/m/CAKFQuwaoBmRuWdMLzLHDCFDJDX3wvfQ7egAF0bpik_BFgG1KWg@mail.gmail.com Author: David G. Johnston Backpatch-through: 13 (cherry picked from commit 2373fe78dfc9d4aa2348a86fffdf8eb9d757e9d5)
2jungkook
approved these changes
Nov 28, 2023
forestkeeper
approved these changes
Nov 28, 2023
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.
25 community commits, no conflicts
Extension PR amazon-aurora/babelfish_extensions#54