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

1ebf00c to 72bc1c1 #55

Merged
merged 14 commits into from
Nov 28, 2023
Merged

1ebf00c to 72bc1c1 #55

merged 14 commits into from
Nov 28, 2023

Conversation

Sairakan
Copy link

@Sairakan Sairakan commented Nov 28, 2023

Cherry-pick of 14 community commits, no conflicts.

Extension PR: amazon-aurora/babelfish_extensions#54

tglsfdc and others added 14 commits November 28, 2023 15:46
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)
@Sairakan Sairakan changed the title Pg16 cherry pick bff 1 1ebf00c to 72bc1c1 Nov 28, 2023
Copy link

@priyansx priyansx left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@priyansx priyansx marked this pull request as ready for review November 28, 2023 16:58
@priyansx priyansx merged commit f710dac into BABEL_main Nov 28, 2023
4 checks passed
@Sairakan Sairakan deleted the pg16-cherry-pick-bff-1 branch November 28, 2023 17:00
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.

9 participants