Commit Graph

56536 Commits

Author SHA1 Message Date
Tom Lane d94dadcc50 Stamp 16rc1. 2023-08-28 16:26:56 -04:00
Peter Eisentraut 66ed5a2e92 Translation updates
Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: a58360c10bd5a0f0153fcf75d0b5291ac1acecb0
2023-08-28 09:23:57 +02:00
Peter Eisentraut ef0e7dbcbe Update list of acknowledgments in release notes
current through a842ba407c
2023-08-27 20:30:53 +02:00
Peter Eisentraut 60d7d50f42 Remove incorrect name from release notes
This name was incorrect in the underlying commit message.  (The
correct name is already listed.)

Reported-by: Denis Laxalde <denis.laxalde@dalibo.com>
2023-08-27 20:29:05 +02:00
Peter Eisentraut 8d70eb731c Remove incorrect/duplicate name from list of acknowledgments
Reported-by: Vik Fearing <vik@postgresfriends.org>
2023-08-27 20:27:32 +02:00
Bruce Momjian a842ba407c doc: PG 16 relnotes: fix initdb encoding/locale item
Reported-by: Jeff Davis

Discussion:  https://postgr.es/m/c5369641862637c71a6c1c440ac7f122068ca4e7.camel@j-davis.com

Backpatch-through: 16 only
2023-08-24 21:44:31 -04:00
Nathan Bossart 2e7d15ab69 pg_upgrade: Bump MESSAGE_WIDTH.
Commit 7b378237aa added a status message to pg_upgrade that is 60
characters wide.  Since the MESSAGE_WIDTH macro is currently set to
60, there is no space between this new status message and the "ok"
or "failed" indicator appended when the step completes.  To fix
this problem, this commit increases the value of MESSAGE_WIDTH to
62.

Suggested-by: Bharath Rupireddy
Reviewed-by: Peter Eisentraut
Discussion: https://postgr.es/m/CALj2ACVVvk1cYLtWVxHv%3DZ1Ubq%3DUES9fhKbUU4c9k4W%2BfEDnbw%40mail.gmail.com
Backpatch-through: 16
2023-08-24 10:13:45 -07:00
Tom Lane ba0d737caa Avoid unnecessary plancache revalidation of utility statements.
Revalidation of a plancache entry (after a cache invalidation event)
requires acquiring a snapshot.  Normally that is harmless, but not
if the cached statement is one that needs to run without acquiring a
snapshot.  We were already aware of that for TransactionStmts,
but for some reason hadn't extrapolated to the other statements that
PlannedStmtRequiresSnapshot() knows mustn't set a snapshot.  This can
lead to unexpected failures of commands such as SET TRANSACTION
ISOLATION LEVEL.  We can fix it in the same way, by excluding those
command types from revalidation.

However, we can do even better than that: there is no need to
revalidate for any statement type for which parse analysis, rewrite,
and plan steps do nothing interesting, which is nearly all utility
commands.  To mechanize this, invent a parser function
stmt_requires_parse_analysis() that tells whether parse analysis does
anything beyond wrapping a CMD_UTILITY Query around the raw parse
tree.  If that's what it does, then rewrite and plan will just
skip the Query, so that it is not possible for the same raw parse
tree to produce a different plan tree after cache invalidation.

stmt_requires_parse_analysis() is basically equivalent to the
existing function analyze_requires_snapshot(), except that for
obscure reasons that function omits ReturnStmt and CallStmt.
It is unclear whether those were oversights or intentional.
I have not been able to demonstrate a bug from not acquiring a
snapshot while analyzing these commands, but at best it seems mighty
fragile.  It seems safer to acquire a snapshot for parse analysis of
these commands too, which allows making stmt_requires_parse_analysis
and analyze_requires_snapshot equivalent.

In passing this fixes a second bug, which is that ResetPlanCache
would exclude ReturnStmts and CallStmts from revalidation.
That's surely *not* safe, since they contain parsable expressions.

Per bug #18059 from Pavel Kulakov.  Back-patch to all supported
branches.

Discussion: https://postgr.es/m/18059-79c692f036b25346@postgresql.org
2023-08-24 12:02:40 -04:00
Peter Eisentraut ce18252d0b Fix lack of message pluralization 2023-08-24 14:22:02 +02:00
Peter Eisentraut 4cdcff4d93 Update DECLARE_INDEX documentation
Update source code comment changes belonging to the changes in
6a6389a08b.

Discussion: https://www.postgresql.org/message-id/flat/75ae5875-3abc-dafc-8aec-73247ed41cde@eisentraut.org
2023-08-24 14:00:36 +02:00
Peter Eisentraut 155c81463c Rename hook functions for debug_io_direct to match variable name.
Commit 319bae9a renamed the GUC.  Rename the check and assign functions
to match, and alphabetize.

Back-patch to 16.

Author: Peter Eisentraut <peter@eisentraut.org>
Discussion: https://postgr.es/m/2769341e-fa28-c2ee-3e4b-53fdcaaf2271%40eisentraut.org
2023-08-24 22:27:53 +12:00
Amit Kapila 13e2665df3 Fix the error message when failing to restore the snapshot.
The SnapBuildRestoreContents() used a const value in the error message to
indicate the size in bytes it was expecting to read from the serialized
snapshot file. Fix it by reporting the size that was actually passed.

Author: Hou Zhijie
Reviewed-by: Amit Kapila
Backpatch-through: 16
Discussion: http://postgr.es/m/OS0PR01MB5716D408364F7DF32221C08D941FA@OS0PR01MB5716.jpnprd01.prod.outlook.com
2023-08-24 14:51:57 +05:30
Peter Eisentraut 8179d1bdf7 Fix translation markers
Conditionals cannot be inside gettext trigger functions, they must be
applied outside.
2023-08-24 10:24:38 +02:00
Peter Eisentraut 8fa09a11c9 pg_upgrade: Improve one log message
The parenthesized plural is unnecessary here and inconsistent with
nearby similar messages.
2023-08-24 08:23:43 +02:00
Bruce Momjian 7d8e703617 do: PG 16 relnotes: clarify last seq/index view names
Backpatch-through: 16 only
2023-08-23 21:33:03 -04:00
David Rowley 5a16984ff1 Meson: check for pg_config_paths.h left over from make
The meson build scripts attempt to find files left over from configure
and fail, mentioning that "make maintainer-clean" should be run to remove
these.  This seems to have been done for files generated from configure.
pg_config_paths.h is generated during the actual make build, so seems to
have been missed.  This would result in compilation using the wrong
pg_config_paths.h file.

Here we just add this file to generated_sources_ac so that meson errors
out if pg_config_paths.h exists.

Likely this wasn't noticed before because make maintainer-clean will
remove pg_config_paths.h, however, people using the MSVC build scripts
are more likely to run into issues and they have to manually remove
these files and pg_config_paths.h wasn't listed as a conflicting file to
remove in the meson log.

Backpatch-through: 16, where meson support was added
Discussion: https://postgr.es/m/CAApHDvqjYOxZfmLKAOWKFEE7LOr9_E6UA6YNmx9r8nxStcS3gg@mail.gmail.com
2023-08-24 10:33:48 +12:00
Andres Freund e8a8cd05d4 ci: Make compute resources for CI configurable
See prior commit for an explanation for the goal of the change and why it had
to be split into two commits.

Reviewed-by: Daniel Gustafsson <daniel@yesql.se>
Reviewed-by: Nazir Bilal Yavuz <byavuz81@gmail.com>
Discussion: https://postgr.es/m/20230808021541.7lbzdefvma7qmn3w@awork3.anarazel.de
Backpatch: 15-, where CI support was added
2023-08-23 15:15:28 -07:00
Andres Freund 9ed46c78a3 ci: Prepare to make compute resources for CI configurable
cirrus-ci will soon restrict the amount of free resources every user gets (as
have many other CI providers). For most users of CI that should not be an
issue. But e.g. for cfbot it will be an issue.

To allow configuring different resources on a per-repository basis, introduce
infrastructure for overriding the task execution environment. Unfortunately
this is not entirely trivial, as yaml anchors have to be defined before their
use, and cirrus-ci only allows injecting additional contents at the end of
.cirrus.yml.

To deal with that, move the definition of the CI tasks to
.cirrus.tasks.yml. The main .cirrus.yml is loaded first, then, if defined, the
file referenced by the REPO_CI_CONFIG_GIT_URL variable, will be added,
followed by the contents of .cirrus.tasks.yml. That allows
REPO_CI_CONFIG_GIT_URL to override the yaml anchors defined in .cirrus.yml.

Unfortunately git's default merge / rebase strategy does not handle copied
files, just renamed ones. To avoid painful rebasing over this change, this
commit just renames .cirrus.yml to .cirrus.tasks.yml, without adding a new
.cirrus.yml. That's done in the followup commit, which moves the relevant
portion of .cirrus.tasks.yml to .cirrus.yml.  Until that is done,
REPO_CI_CONFIG_GIT_URL does not fully work.

The subsequent commit adds documentation for how to configure custom compute
resources to src/tools/ci/README

Reviewed-by: Daniel Gustafsson <daniel@yesql.se>
Reviewed-by: Nazir Bilal Yavuz <byavuz81@gmail.com>
Discussion: https://postgr.es/m/20230808021541.7lbzdefvma7qmn3w@awork3.anarazel.de
Backpatch: 15-, where CI support was added
2023-08-23 15:15:28 -07:00
Andres Freund f518c909ea ci: Use VMs for SanityCheck and CompilerWarnings
The main reason for this change is to reduce different ways of executing
tasks, making it easier to use custom compute resources for cfbot. A secondary
benefit is that the tasks seem slightly faster this way, apparently the
increased startup overhead is outweighed by reduced runtime overhead.

Reviewed-by: Daniel Gustafsson <daniel@yesql.se>
Discussion: https://postgr.es/m/20230808021541.7lbzdefvma7qmn3w@awork3.anarazel.de
Backpatch: 15-, where CI support was added
2023-08-23 12:29:50 -07:00
Andres Freund cad461b044 ci: Move execution method of tasks into yaml templates
This is done in preparation for making the compute resources for CI
configurable. It also looks cleaner.

Reviewed-by: Daniel Gustafsson <daniel@yesql.se>
Discussion: https://postgr.es/m/20230808021541.7lbzdefvma7qmn3w@awork3.anarazel.de
Backpatch: 15-, where CI support was added
2023-08-23 12:27:40 -07:00
Andres Freund 5581a9a395 ci: Don't specify amount of memory
The number of CPUs is the cost-determining factor. Most instance types that
run tests have more memory/core than what we specified, there's no real
benefit in wasting that.

Reviewed-by: Daniel Gustafsson <daniel@yesql.se>
Discussion: https://postgr.es/m/20230808021541.7lbzdefvma7qmn3w@awork3.anarazel.de
Backpatch: 15-, where CI support was added
2023-08-23 12:27:29 -07:00
Heikki Linnakangas c3b874c431 Fix _bt_allequalimage() call within critical section.
_bt_allequalimage() does complicated things, so it's not OK to call it
in a critical section. Per buildfarm failure on 'prion', which uses
-DRELCACHE_FORCE_RELEASE -DCATCACHE_FORCE_RELEASE options.

Discussion: https://www.postgresql.org/message-id/6e5bbc08-cdfc-b2b3-9e23-1a914b9850a9@iki.fi
Backpatch-through: 16, like commit ccadf73163 that introduced this
2023-08-23 18:11:51 +03:00
Heikki Linnakangas 6bc1fd4e60 Use the buffer cache when initializing an unlogged index.
Some of the ambuildempty functions used smgrwrite() directly, followed
by smgrimmedsync(). A few small problems with that:

Firstly, one is supposed to use smgrextend() when extending a
relation, not smgrwrite(). It doesn't make much difference in
production builds. smgrextend() updates the relation size cache, so
you miss that, but that's harmless because we never use the cached
relation size of an init fork. But if you compile with
CHECK_WRITE_VS_EXTEND, you get an assertion failure.

Secondly, the smgrwrite() calls were performed before WAL-logging, so
the page image written to disk had 0/0 as the LSN, not the LSN of the
WAL record. That's also harmless in practice, but seems sloppy.

Thirdly, it's better to use the buffer cache, because then you don't
need to smgrimmedsync() the relation to disk, which adds latency.
Bypassing the cache makes sense for bulk operations like index
creation, but not when you're just initializing an empty index.
Creation of unlogged tables is hardly performance bottleneck in any
real world applications, but nevertheless.

Backpatch to v16, but no further. These issues should be harmless in
practice, so better to not rock the boat in older branches.

Reviewed-by: Robert Haas
Discussion: https://www.postgresql.org/message-id/6e5bbc08-cdfc-b2b3-9e23-1a914b9850a9@iki.fi
2023-08-23 17:23:18 +03:00
Daniel Gustafsson 5fd424c87a doc: Replace list of drivers and PLs with wiki link
The list of external language drivers and procedural languages was
never complete or exhaustive, and rather than attempting to manage
it the content has migrated to the wiki.  This replaces the tables
altogether with links to the wiki as we regularly get requests for
adding various projects,  which we reject without any clear policy
for why or how the content should be managed.

The threads linked to below are the most recent discussions about
this, the archives contain many more.

Backpatch to all supported branches since the list on the wiki
applies to all branches.

Author: Jonathan Katz <jkatz@postgresql.org>
Discussion: https://postgr.es/m/169165415312.635.10247434927885764880@wrigleys.postgresql.org
Discussion: https://postgr.es/m/169177958824.635.11087800083040275266@wrigleys.postgresql.org
Backpatch-through: v11
2023-08-23 14:13:07 +02:00
Peter Eisentraut 103df207a7 doc: Add more ICU rules examples
In particular, add an example EBCDIC collation.

Author: Daniel Verite <daniel@manitou-mail.org>
Discussion: https://www.postgresql.org/message-id/flat/35cc1684-e516-4a01-a256-351632d47066@manitou-mail.org
2023-08-23 11:24:43 +02:00
Peter Eisentraut 0b9127de12 doc: Improve ICU external link
It previously pointed to the collation API documentation, which our
users don't need, but the containing chapter seems useful.
2023-08-23 08:26:53 +02:00
Peter Eisentraut 6f168e077e Improve vertical spacing of documentation markup 2023-08-23 08:13:22 +02:00
Thomas Munro f58af9f416 ExtendBufferedWhat -> BufferManagerRelation.
Commit 31966b15 invented a way for functions dealing with relation
extension to accept a Relation in online code and an SMgrRelation in
recovery code.  It seems highly likely that future bufmgr.c interfaces
will face the same problem, and need to do something similar.
Generalize the names so that each interface doesn't have to re-invent
the wheel.

Back-patch to 16.  Since extension AM authors might start using the
constructor macros once 16 ships, we agreed to do the rename in 16
rather than waiting for 17.

Reviewed-by: Peter Geoghegan <pg@bowt.ie>
Reviewed-by: Andres Freund <andres@anarazel.de>
Discussion: https://postgr.es/m/CA%2BhUKG%2B6tLD2BhpRWycEoti6LVLyQq457UL4ticP5xd8LqHySA%40mail.gmail.com
2023-08-23 12:33:24 +12:00
Bruce Momjian d8cd49e992 doc: PG 16 relnotes: properly indent and word-wrap text
Backpatch-through: 16 only
2023-08-22 19:37:26 -04:00
Jeff Davis 501704e826 Fix pg_dump assertion failure when dumping pg_catalog.
Commit 396d348b04 did not account for the default collation.

Also, use pg_log_warning() instead of Assert().

Discussion: https://postgr.es/m/ce071503fee88334aa70f360e6e4ea14d48305ee.camel%40j-davis.com
Reviewed-by: Michael Paquier
Backpatch-through: 15
2023-08-22 12:49:40 -07:00
Andrew Dunstan f938acd68b Cache by-reference missing values in a long lived context
Attribute missing values might be needed past the lifetime of the tuple
descriptors from which they are extracted. To avoid possibly using
pointers for by-reference values which might thus be left dangling, we
cache a datumCopy'd version of the datum in the TopMemoryContext. Since
we first search for the value this only needs to be done once per
session for any such value.

Original complaint from Tom Lane, idea for mitigation by Andrew Dunstan,
tweaked by Tom Lane.

Backpatch to version 11 where missing values were introduced.

Discussion: https://postgr.es/m/1306569.1687978174@sss.pgh.pa.us
2023-08-22 15:18:19 -04:00
Bruce Momjian e9f535463a doc: PG 16 relnotes: separate out psql \drg item
Reported-by: Pavel Luzanov

Discussion: https://postgr.es/m/29b97504-80a3-fdcc-538e-cadde3d8ecd5@postgrespro.ru

Backpatch-through: 16 only
2023-08-22 15:15:24 -04:00
Peter Eisentraut 8c76a55665 Add list of acknowledgments to release notes
This contains all individuals mentioned in the commit messages during
PostgreSQL 16 development.

current through REL_16_BETA3
2023-08-22 11:20:39 +02:00
Bruce Momjian 7fb906d80a doc: PG 16 relnotes: adjust RANGE/ROWS window item
Reported-by: Erwin Brandstetter

Discussion: https://postgr.es/m/CAGHENJ5Cj3wBH07YM5Lw2h5q8s65cNg_NEdkkWvmRo+vOormWw@mail.gmail.com

Backpatch-through: 16 only
2023-08-21 18:55:41 -04:00
Bruce Momjian 00be0bc3d5 doc: PG 16 relnotes: move role INHERIT item and clarify it
Also split out new role ADMIN syntax entry.

Reported-by: Pavel Luzanov

Discussion: https://postgr.es/m/0ebcc8ea-7f5a-d014-d53f-e078622be35d@aklaver.com

Backpatch-through: 16 only
2023-08-21 17:54:29 -04:00
Michael Paquier d6af45052d Fix pg_stat_reset_single_table_counters() for shared relations
This commit fixes the function of $subject for shared relations.  This
feature has been added by e042678.  Unfortunately, this new behavior got
removed by 5891c7a when moving statistics to shared memory.

Reported-by: Mitsuru Hinata
Author: Masahiro Ikeda
Reviewed-by: Kyotaro Horiguchi, Masahiko Sawada
Discussion: https://postgr.es/m/7cc69f863d9b1bc677544e3accd0e4b4@oss.nttdata.com
Backpatch-through: 15
2023-08-21 13:33:04 +09:00
Andres Freund dd2a731d9c ci: macos: use cached macports install
A significant chunk of the time on the macos CI task is spent installing
packages using homebrew. The downloads of the packages are cached, but the
installation needs to happen every time. We can't cache the whole homebrew
installation, because it is too large due to pre-installed packages.

Speed this up by installing packages using macports and caching the
installation as .dmg. That's a lot faster than unpacking a tarball.

In addition, don't install llvm - it wasn't enabled when building, so it's
just a waste of time/space.

This substantially speeds up the mac CI time, both in the cold cache and in
the warm cache case (the latter from ~1m20s to ~5s).

It doesn't seem great to have diverging sources of packages for CI between
branches, so backpatch to 15 (where CI was added).

Discussion: https://postgr.es/m/20230805202539.r3umyamsnctysdc7@awork3.anarazel.de
Backpatch: 15-, where CI was added
2023-08-19 14:38:56 -07:00
Peter Eisentraut dcfc49c1b6 Remove dubious warning message from SQL/JSON functions
There was a warning that FORMAT JSON has no effect on json/jsonb
types, which is true, but it's not clear why we should issue a warning
about it.  The SQL standard does not say anything about this, which
should generally govern the behavior here.  So remove it.

Discussion: https://www.postgresql.org/message-id/flat/dfec2cae-d17e-c508-6d16-c2dba82db486%40eisentraut.org
2023-08-18 07:43:52 +02:00
Thomas Munro 6337e994e8 Invalidate smgr_targblock in smgrrelease().
In rare circumstances involving relfilenode reuse, it might have been
possible for smgr_targblock to finish up pointing past the end.

Oversight in b74e94dc.  Back-patch to 15.

Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi>
Discussion: https://postgr.es/m/CA%2BhUKGJ8NTvqLHz6dqbQnt2c8XCki4r2QvXjBQcXpVwxTY_pvA%40mail.gmail.com
2023-08-17 15:54:04 +12:00
Bruce Momjian 11f4935490 doc: PG 16 relnotes, add links to doc sections
Backpatch-through: 16 only
2023-08-16 22:22:12 -04:00
Bruce Momjian 6b86a3e0b4 doc: PG 16 relnotes, initial markup
Still need to add links to doc sections.

Backpatch-through: 16 only
2023-08-16 14:34:49 -04:00
Peter Eisentraut c672262779 Unify some error messages
We had essentially the same error in several different wordings.
Unify that.
2023-08-16 16:18:49 +02:00
Peter Eisentraut 842b659050 Improved CREATE SUBSCRIPTION message for clarity
Discussion: https://www.postgresql.org/message-id/CAHut+PtfzQ7JRkb0-Y_UejAxaLQ17-bGMvV4MJJHcPoP3ML2bg@mail.gmail.com
2023-08-16 15:09:50 +02:00
Bruce Momjian c5c8bd29b9 doc: PG 16 relnotes, update "current as of" date
Backpatch-through: 16 only
2023-08-15 09:15:21 -04:00
Thomas Munro acc5c4fd8f De-pessimize ConditionVariableCancelSleep().
Commit b91dd9de was concerned with a theoretical problem with our
non-atomic condition variable operations.  If you stop sleeping, and
then cancel the sleep in a separate step, you might be signaled in
between, and that could be lost.  That doesn't matter for callers of
ConditionVariableBroadcast(), but callers of ConditionVariableSignal()
might be upset if a signal went missing like this.

Commit bc971f4025 interacted badly with that logic, because it doesn't
use ConditionVariableSleep(), which would normally put us back in the
wait list.  ConditionVariableCancelSleep() would be confused and think
we'd received an extra signal, and try to forward it to another backend,
resulting in wakeup storms.

New idea: ConditionVariableCancelSleep() can just return true if we've
been signaled.  Hypothetical users of ConditionVariableSignal() would
then still have a way to deal with rare lost signals if they are
concerned about that problem.

Back-patch to 16, where bc971f4025 arrived.

Reported-by: Tomas Vondra <tomas.vondra@enterprisedb.com>
Reviewed-by: Andres Freund <andres@anarazel.de>
Discussion: https://postgr.es/m/2840876b-4cfe-240f-0a7e-29ffd66711e7%40enterprisedb.com
2023-08-15 10:33:55 +12:00
Bruce Momjian 03fb43f6ed doc: PG 16 relnotes: udpate for commits since branching
Backpatch-through: 16 only
2023-08-14 17:28:39 -04:00
Andres Freund d37ab378b6 hio: Take number of prior relation extensions into account
The new relation extension logic, introduced in 00d1e02be2, could lead to
slowdowns in some scenarios. E.g., when loading narrow rows into a table using
COPY, the caller of RelationGetBufferForTuple() will only request a small
number of pages. Without concurrency, we just extended using pwritev() in that
case. However, if there is *some* concurrency, we switched between extending
by a small number of pages and a larger number of pages, depending on the
number of waiters for the relation extension logic.  However, some
filesystems, XFS in particular, do not perform well when switching between
extending files using fallocate() and pwritev().

To avoid that issue, remember the number of prior relation extensions in
BulkInsertState and extend more aggressively if there were prior relation
extensions. That not just avoids the aforementioned slowdown, but also leads
to noticeable performance gains in other situations, primarily due to
extending more aggressively when there is no concurrency. I should have done
it this way from the get go.

Reported-by: Masahiko Sawada <sawada.mshk@gmail.com>
Author: Andres Freund <andres@anarazel.de>
Discussion: https://postgr.es/m/CAD21AoDvDmUQeJtZrau1ovnT_smN940=Kp6mszNGK3bq9yRN6g@mail.gmail.com
Backpatch: 16-, where the new relation extension code was added
2023-08-14 09:54:38 -07:00
Andres Freund 2243ef8dd6 ci: macos: Remove use of -Dsegsize_blocks=6
The option causes a measurable slowdown. Macos is, by far, the most expensive
platform for CI, therefore it doesn't make sense to run such a test there.

d3b111e320 used a small segment size for two tasks, one with autoconf, one
with meson. In hindsight that is a bit overkill, it's unlikely that the option
would silently break. Thus don't move the -Dsegsize_blocks=6, just remove
it. I did however change the autoconf test to use 6 instead of 8 blocks, as
long as we allow it, a non-power-of-two test seems like a good idea.

While at it, add a comment explaining why we use a small segment size for CI.

Author: Andres Freund <andres@anarazel.de>
Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi>
Discussion: https://postgr.es/m/20230808021541.7lbzdefvma7qmn3w@awork3.anarazel.de
Backpatch: 16-, where d3b111e320 introduced the use of -Dsegsize_blocks=6
2023-08-12 15:08:08 -07:00
Andres Freund 4bec616f26 ci: macos: Remove use of -DRANDOMIZE_ALLOCATED_MEMORY
RANDOMIZE_ALLOCATED_MEMORY causes a measurable slowdown. Macos is, by far, the
most expensive platform for CI, therefore it doesn't make sense to run such a
test there.

Ubsan and asan on linux should detect most of the the cases of uninitialized
memory, so it doesn't really seem worth using -DRANDOMIZE_ALLOCATED_MEMORY in
another instance type.

Author: Andres Freund <andres@anarazel.de>
Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi>
Discussion: https://postgr.es/m/20230808021541.7lbzdefvma7qmn3w@awork3.anarazel.de
Backpatch: 16-, where 89d16b635 added the use of -DRANDOMIZE_ALLOCATED_MEMORY
2023-08-12 15:08:07 -07:00
Noah Misch 7823a298ba Fix off-by-one in XLogRecordMaxSize check.
pg_logical_emit_message(false, '_', repeat('x', 1069547465)) failed with
self-contradictory message "WAL record would be 1069547520 bytes (of
maximum 1069547520 bytes)".  There's no particular benefit from allowing
or denying one byte in either direction; XLogRecordMaxSize could rise a
few megabytes without trouble.  Hence, this is just for cleanliness.
Back-patch to v16, where this check first appeared.
2023-08-12 14:37:11 -07:00