Skip to content
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
merged 25 commits into from
Nov 29, 2023

Conversation

Sairakan
Copy link

@Sairakan Sairakan commented Nov 28, 2023

25 community commits, no conflicts

Extension PR amazon-aurora/babelfish_extensions#54

anarazel and others added 25 commits November 28, 2023 18:45
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)
@Sairakan Sairakan marked this pull request as ready for review November 28, 2023 20:21
@priyansx priyansx merged commit 339758a into BABEL_main Nov 29, 2023
4 checks passed
@Sairakan Sairakan deleted the pg16-cherry-pick-bff-1 branch November 29, 2023 02:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.