Commit Graph

54738 Commits

Author SHA1 Message Date
Tom Lane
40ad8f9dee Implement WRITE_READ_PARSE_PLAN_TREES for raw parse trees
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/4159834.1657405226@sss.pgh.pa.us
2022-09-26 16:32:16 +02:00
Peter Eisentraut
acd624644b Don't lose precision for float fields of Nodes.
Historically we've been more worried about making the output of
float fields look pretty than whether they'd be read back exactly.
That won't work if we're to compare the read-back nodes for
equality, so switch to using the Ryu code for float output.

Author: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/4159834.1657405226@sss.pgh.pa.us
2022-09-26 16:02:09 +02:00
Peter Eisentraut
c07785d458 catversion bump
for 8999f5ed3c
2022-09-26 15:56:47 +02:00
Peter Eisentraut
8999f5ed3c Fix write/read of empty string fields in Nodes.
Historically, outToken has represented both NULL and empty-string
strings as "<>", which readfuncs.c then read as NULL, thus failing
to preserve empty-string fields accurately.  Remarkably, this has
not caused any serious problems yet, but let's fix it.

We'll keep the "<>" notation for NULL, and use """" for empty string,
because that matches other notational choices already in use.
An actual input string of """" is converted to "\""" (this was true
already, apparently as a hangover from an ancient time when string
quoting was handled directly by pg_strtok).

CHAR fields also use "<>", but for '\0'.

Author: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/4159834.1657405226@sss.pgh.pa.us
2022-09-26 15:25:59 +02:00
Amit Kapila
af51b2f042 Remove unused xid parameter.
Commit 6c2003f8a1 removes the use of transaction id's for exporting
snapshots. This commit removes one unused xid parameter left behind in
SnapBuildGetOrBuildSnapshot.

Author: Melih Mutlu
Reviewed-By: Zhang Mingli
Discussion: https://postgr.es/m/CAGPVpCTqZRoDKgCycw+eYi+Gq41rN9pU-gntgTd7wfsNDpPL3Q@mail.gmail.com
2022-09-26 08:47:00 +05:30
Michael Paquier
7d708093b7 Refactor creation of backup_label and backup history files
This change simplifies some of the logic related to the generation and
creation of the backup_label and backup history files, which has become
unnecessarily complicated since the removal of the exclusive backup mode
in commit 39969e2.  The code was previously generating the contents of
these files as a string (start phase for the backup_label and stop phase
for the backup history file), one problem being that the contents of the
backup_label string were scanned to grab some of its internal contents
at the stop phase.

This commit changes the logic so as we store the data required to build
these files in an intermediate structure named BackupState.  The
backup_label file and backup history file strings are generated when
they are ready to be sent back to the client.  Both files are now
generated with the same code path.  While on it, this commit renames
some variables for clarity.

Two new files named xlogbackup.{c,h} are introduced in this commit, to
remove from xlog.c some of the logic around base backups.  Note that
more could be moved to this new set of files.

Author: Bharath Rupireddy, Michael Paquier
Reviewed-by: Fujii Masao
Discussion: https://postgr.es/m/CALj2ACXWwTDgJqCjdaPyfR7djwm6SrybGcrZyrvojzcsmt4FFw@mail.gmail.com
2022-09-26 11:15:47 +09:00
Tom Lane
216f9c1ab3 Fix tupdesc lifespan bug with AfterTriggersTableData.storeslot.
Commit 25936fd46 adjusted things so that the "storeslot" we use
for remapping trigger tuples would have adequate lifespan, but it
neglected to consider the lifespan of the tuple descriptor that
the slot depends on.  It turns out that in at least some cases, the
tupdesc we are passing is a refcounted tupdesc, and the refcount for
the slot's reference can get assigned to a resource owner having
different lifespan than the slot does.  That leads to an error like
"tupdesc reference 0x7fdef236a1b8 is not owned by resource owner
SubTransaction".  Worse, because of a second oversight in the same
commit, we'd try to free the same tupdesc refcount again while
cleaning up after that error, leading to recursive errors and an
"ERRORDATA_STACK_SIZE exceeded" PANIC.

To fix the initial problem, let's just make a non-refcounted copy
of the tupdesc we're supposed to use.  That seems likely to guard
against additional problems, since there's no strong reason for
this code to assume that what it's given is a refcounted tupdesc;
in which case there's an independent hazard of the tupdesc having
shorter lifespan than the slot does.  (I didn't bother trying to
free said copy, since it should go away anyway when the (sub)
transaction context is cleaned up.)

The other issue can be fixed by making the code added to
AfterTriggerFreeQuery work like the rest of that function, ie be
sure that it doesn't try to free the same slot twice in the event
of recursive error cleanup.

While here, also clean up minor stylistic issues in the test case
added by 25936fd46: don't use "create or replace function", as any
name collision within the tests is likely to have ill effects
that that won't mask; and don't use function names as generic as
trigger_function1, especially if you're not going to drop them
at the end of the test stanza.

Per bug #17607 from Thomas Mc Kay.  Back-patch to v12, as the
previous fix was.

Discussion: https://postgr.es/m/17607-bd8ccc81226f7f80@postgresql.org
2022-09-25 17:10:58 -04:00
Tom Lane
1d2fec990c Avoid loss of code coverage with unlogged-index test cases.
Commit 4fb5c794e intended to add coverage of some ambuildempty
methods that were not getting reached, without removing any
test coverage.  However, by changing a temp table to unlogged
it managed to negate the intent of 4c51a2d1e, which means that
we didn't have reliable test coverage of ginvacuum.c anymore.
As things stand, much of that file might or might not get reached
depending on timing, which seems pretty undesirable.

Although this is only clearly broken for the GIN test, it seems
best to revert 4fb5c794e altogether and instead add bespoke test
cases covering unlogged indexes for these four AMs.  We don't
need to do very much with them, so the extra tests are cheap.
(Note that btree, hash, and bloom already have similar test cases,
so they need no additional work.)

We can also undo dec8ad367.  Since the testing deficiency that that
hacked around was later fixed by 2f2e24d90, let's intentionally leave
an unlogged table behind to improve test coverage in the modules that
use the regression database for other test purposes.  (The case I used
also leaves an unlogged sequence behind.)

Per report from Alex Kozhemyakin.  Back-patch to v15 where the
faulty test came in.

Discussion: https://postgr.es/m/b00c8ee096ee46cd25c183125562a1a7@postgrespro.ru
2022-09-25 13:10:17 -04:00
Alvaro Herrera
dda101315a
Add missing source files to pg_waldump/nls.mk 2022-09-25 17:48:03 +02:00
Peter Eisentraut
26f7802beb Message style improvements 2022-09-24 18:41:25 -04:00
Peter Eisentraut
a6bc330192 Add read support for some missing raw parse nodes
The node types A_Const, Constraint, and A_Expr had custom output
functions, but no read functions were implemented so far.

The A_Expr output format had to be tweaked a bit to make it easier to
parse.

Be a bit more cautious about applying strncmp to unterminated strings.

Also error out if an unrecognized enum value is found in each case,
instead of just printing a placeholder value.  That was maybe ok for
debugging but won't work if we want to have robust round-tripping.

Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/4159834.1657405226@sss.pgh.pa.us
2022-09-24 18:18:33 -04:00
Peter Eisentraut
2cb1a5a8d4 Fix reading of BitString nodes
The node tokenizer went out of its way to store BitString node values
without the leading 'b'.  But everything else in the system stores the
leading 'b'.  This would break if a BitString node is
read-printed-read.

Also, the node tokenizer didn't know that BitString node tokens could
also start with 'x'.

Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/4159834.1657405226@sss.pgh.pa.us
2022-09-24 18:10:52 -04:00
Peter Eisentraut
43f4b34915 Fix reading of most-negative integer value nodes
The main parser checks whether a literal fits into an int when
deciding whether it should be put into an Integer or Float node.  The
parser processes integer literals without signs.  So a most-negative
integer literal will not fit into Integer and will end up as a Float
node.

The node tokenizer did this differently.  It included the sign when
checking whether the literal fit into int.  So a most-negative integer
would indeed fit that way and end up as an Integer node.

In order to preserve the node structure correctly, we need the node
tokenizer to also analyze integer literals without sign.

There are a number of test cases in the regression tests that have a
most-negative integer argument of some utility statement, so this
issue is easily reproduced under WRITE_READ_PARSE_PLAN_TREES.

Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/4159834.1657405226@sss.pgh.pa.us
2022-09-24 18:10:11 -04:00
Andres Freund
03bf971d2d Remove uses of register due to incompatibility with C++17 and up
The use in regexec.c could remain, since we only try to keep headers C++
clean. But there really doesn't seem to be a good reason to use register in
that spot.

Discussion: https://postgr.es/m/20220308185902.ibdqmasoaunzjrfc@alap3.anarazel.de
2022-09-24 12:08:37 -07:00
Andres Freund
eef63941c1 De-special-case pgevent's rc file handling
There's really no need to build win32ver.rc as part of building
pgmsgevent.rc. This will make it sligthly easier to add rc file generation to
the meson build.
2022-09-24 12:04:56 -07:00
Andres Freund
a075c616d2 meson: Remove non-binary targets accidentally added to bin_targets 2022-09-24 11:29:30 -07:00
Peter Eisentraut
6d6e136872 Improve terminology
Use "prepared transaction" instead of "two-phrase transaction".  This
is in line with 0e60a50e0b.
2022-09-23 21:18:17 -04:00
Tom Lane
5f1048881d Doc: minor cleanups.
Improve a couple of things I noticed while working on v15
release notes.
2022-09-23 18:20:14 -04:00
Andres Freund
d811ce6ea3 pgstat: Fix transactional stats dropping for indexes
Because index creation does not go through heap_create_with_catalog() we
didn't call pgstat_create_relation(), leading to index stats of a newly
created realtion not getting dropped during rollback. To fix, move the
pgstat_create_relation() to heap_create(), which indexes do use.

Similarly, because dropping an index does not go through
heap_drop_with_catalog(), we didn't drop index stats when the transaction
dropping an index committed. Here there's no convenient common path for
indexes and relations, so index_drop() now calls pgstat_drop_relation().

Add tests for transactional index stats handling.

Author: "Drouvot, Bertrand" <bdrouvot@amazon.com>
Reviewed-by: Andres Freund <andres@anarazel.de>
Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Discussion: https://postgr.es/m/51bbf286-2b4a-8998-bd12-eaae4b765d99@amazon.com
Backpatch: 15-, like 8b1dccd37c, which introduced the bug
2022-09-23 13:00:55 -07:00
Alvaro Herrera
0032a54567
Remove PQsendQuery support in pipeline mode
The extended query protocol implementation I added in commit
acb7e4eb6b has bugs when used in pipeline mode.  Rather than spend
more time trying to fix it, remove that code and make the function rely
on simple query protocol only, meaning it can no longer be used in
pipeline mode.

Users can easily change their applications to use PQsendQueryParams
instead.  We leave PQsendQuery in place for Postgres 14, just in case
somebody is using it and has not hit the mentioned bugs; but we should
recommend that it not be used.

Backpatch to 15.

Per bug report from Gabriele Varrazzo.
Discussion: https://postgr.es/m/CA+mi_8ZGSQNmW6-mk_iSR4JZB_LJ4ww3suOF+1vGNs3MrLsv4g@mail.gmail.com
2022-09-23 18:21:22 +02:00
Alvaro Herrera
d11a41a4ce
Stop using PQsendQuery in libpq_pipeline
The "emulation" I wrote for PQsendQuery in pipeline mode to use extended
query protocol, in commit acb7e4eb6b, is problematic.  Due to numerous
bugs we'll soon remove it.  As a first step and for all branches back to
14, stop using PQsendQuery in libpq_pipeline.  Also remove a few test
lines that will no longer be relevant.

Backpatch to 14.

Discussion: https://postgr.es/m/CA+mi_8ZGSQNmW6-mk_iSR4JZB_LJ4ww3suOF+1vGNs3MrLsv4g@mail.gmail.com
2022-09-23 18:11:48 +02:00
Andres Freund
e3e6ee6964 ci: freebsd: Set extra_{lib,include}_dirs to /usr/local/...
Ommitted in e6b6ea025c, but necessary for libintl to be found. All other
dependencies can be found via pkg-config (which searches in /usr/local/...)
and thus worked even without adding the directories.
2022-09-22 20:42:06 -07:00
Amit Kapila
13a185f54b Allow publications with schema and table of the same schema.
We previously thought that allowing such cases can confuse users when they
specify DROP TABLES IN SCHEMA but that doesn't seem to be the case based
on discussion. This helps to uplift the restriction during
ALTER TABLE ... SET SCHEMA which used to ensure that we couldn't end up
with a publication having both a schema and the same schema's table.

To allow this, we need to forbid having any schema on a publication if
column lists on a table are specified (and vice versa). This is because
otherwise we still need a restriction during ALTER TABLE ... SET SCHEMA to
forbid cases where it could lead to a publication having both a schema and
the same schema's table with column list.

Based on suggestions by Peter Eisentraut.

Author: Hou Zhijie and Vignesh C
Reviewed-By: Peter Smith, Amit Kapila
Backpatch-through: 15, where it was introduced
Discussion: https://postgr.es/m/2729c9e2-9aac-8cda-f2f4-34f2bcc18f4e@enterprisedb.com
2022-09-23 08:21:26 +05:30
Tom Lane
d89755dac6 Doc: adjust misleading phrasing of a few cross-references.
The pg_dump and pg_dumpall man pages referred to app-psql-patterns
as appearing "below", which I suspect was copied-and-pasted from
equivalent text in psql-ref.sgml rather than being actually thought
through.  At least to me, that phrasing means "later in this same
web page/section", which this link target is not.  Drop the
misleading and unnecessary-in-any-case adjective.
2022-09-22 22:05:09 -04:00
Peter Geoghegan
20e69daa13 Harmonize parameter names in pg_dump/pg_dumpall.
Make sure that function declarations use names that exactly match the
corresponding names from function definitions in pg_dump/pg_dumpall
related code.

Affected code happens to be inconsistent in how it applies conventions
around how Archive and Archive Handle variables are named.  Significant
code churn is required to fully fix those inconsistencies, so take the
least invasive approach possible: treat function definition names as
authoritative, and mechanically adjust corresponding names from function
definitions to match.

Like other recent commits that cleaned up function parameter names, this
commit was written with help from clang-tidy.

Author: Peter Geoghegan <pg@bowt.ie>
Reviewed-By: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/CAH2-Wzmma+vzcO6gr5NYDZ+sx0G14aU-UrzFutT2FoRaisVCUQ@mail.gmail.com
2022-09-22 16:41:23 -07:00
Peter Geoghegan
0faf7d933f Harmonize parameter names in contrib code.
Make sure that function declarations use names that exactly match the
corresponding names from function definitions in contrib code.

Like other recent commits that cleaned up function parameter names, this
commit was written with help from clang-tidy.

Author: Peter Geoghegan <pg@bowt.ie>
Discussion: https://postgr.es/m/CAH2-WznJt9CMM9KJTMjJh_zbL5hD9oX44qdJ4aqZtjFi-zA3Tg@mail.gmail.com
2022-09-22 13:59:20 -07:00
Peter Geoghegan
8fb4e001e9 Harmonize more lexer function parameter names.
Make sure that function declarations use names that exactly match the
corresponding names from function definitions for several "lexer
adjacent" backend functions.  These were missed by commit aab06442.

Author: Peter Geoghegan <pg@bowt.ie>
Discussion: https://postgr.es/m/CAH2-WznJt9CMM9KJTMjJh_zbL5hD9oX44qdJ4aqZtjFi-zA3Tg@mail.gmail.com
2022-09-22 13:27:16 -07:00
Peter Geoghegan
3535ebce5d Harmonize parameter names in ecpg code.
Make ecpg function declarations consistently use named parameters.  Also
make sure that the declarations use names that match corresponding names
from function definitions.

Like other recent commits that cleaned up function parameter names, this
commit was written with help from clang-tidy.

Author: Peter Geoghegan <pg@bowt.ie>
Reviewed-By: David Rowley <dgrowleyml@gmail.com>
Discussion: https://postgr.es/m/CAH2-WznJt9CMM9KJTMjJh_zbL5hD9oX44qdJ4aqZtjFi-zA3Tg@mail.gmail.com
2022-09-22 12:53:20 -07:00
Jeff Davis
163b0993a1 Fix race condition where heap_delete() fails to pin VM page.
Similar to 5f12bc94dc, the code must re-check PageIsAllVisible() after
buffer lock is re-acquired. Backpatching to the same version, 12.

Discussion: https://postgr.es/m/CAEP4nAw9jYQDKd_5Y+-s2E4YiUJq1vqiikFjYGpLShtp-K3gag@mail.gmail.com
Reported-by: Robins Tharakan
Reviewed-by: Robins Tharakan
Backpatch-through: 12
2022-09-22 11:04:00 -07:00
Alvaro Herrera
790bf615dd
Remove ALL keyword from TABLES IN SCHEMA for publication
This may be a bit too subtle, but removing that word from there makes
this clause no longer a perfect parallel of the GRANT variant "ALL
TABLES IN SCHEMA": indeed, for publications what we record is the schema
itself, not the tables therein, which means that any tables added to the
schema in the future are also published.  This is completely different
to what GRANT does, which is affect only the tables that exist when the
command is executed.

There isn't resounding support for this change, but there are a few
positive votes and no opposition.  Because the time to 15 RC1 is very
short, let's get this out now.

Backpatch to 15.

Discussion: https://postgr.es/m/2729c9e2-9aac-8cda-f2f4-34f2bcc18f4e
2022-09-22 19:02:25 +02:00
Peter Eisentraut
ba50834551 Restore archive_command documentation
Commit 5ef1eefd76, which added
archive_library, purged most mentions of archive_command from the
documentation.  This is inappropriate, since archive_command is still
a feature in use and users will want to see information about it.

This restores all the removed mentions and rephrases things so that
archive_command and archive_library are presented as alternatives of
each other.

Reviewed-by: Nathan Bossart <nathandbossart@gmail.com>
Discussion: https://www.postgresql.org/message-id/9366d634-a917-85a9-4991-b2a4859edaf9@enterprisedb.com
2022-09-22 07:35:00 -04:00
Michael Paquier
18ac08f0b4 Use min/max bounds defined by Zstd for compression level
The bounds hardcoded in compression.c since ffd5365 (minimum at 1 and
maximum at 22) do not match the reality of what zstd is able to
handle, these values being available via ZSTD_maxCLevel() and
ZSTD_minCLevel() at run-time.  The maximum of 22 is actually correct
in recent versions, but the minimum was not as the library can go down
to -131720 by design.  This commit changes the code to use the run-time
values in the code instead of some hardcoded ones.

Zstd seems to assume that these bounds could change in the future, and
Postgres will be able to adapt automatically to such changes thanks to
what's being done in this commit.

Reported-by: Justin Prysby
Discussion: https://postgr.es/m/20220922033716.GL31833@telsasoft.com
Backpatch-through: 15
2022-09-22 20:02:40 +09:00
Etsuro Fujita
cbe6dd17ac Fix thinko in comment.
This comment has been wrong since its introduction in commit 0d5f05cde;
backpatch to v12 where that came in.

Discussion: https://postgr.es/m/CAPmGK14VGf-xQjGQN4o1QyAbXAaxugU5%3DqfcmTDh1iufUDnV_w%40mail.gmail.com
2022-09-22 15:55:00 +09:00
Andres Freund
e6b6ea025c meson: ci: Convert some tasks to use meson
The Windows task is changed to use meson as there currently is no way to run
all tests in the old MSVC build system (only ninja is covered for now, we
don't have enough CI resources to test msbuild as well).

To maintain autoconf coverage, the Linux task is duplicated to test both meson
and autoconf builds (linux is currently the fastest task). FreeBSD and macOS
are also converted to meson, as it seems more important to have coverage for
meson than autoconf.

Author: Andres Freund <andres@anarazel.de>
Author: Nazir Bilal Yavuz <byavuz81@gmail.com>
Author: Justin Pryzby <pryzby@telsasoft.com>
2022-09-21 22:46:18 -07:00
Andres Freund
e6927270cd meson: Add initial version of meson based build system
Autoconf is showing its age, fewer and fewer contributors know how to wrangle
it. Recursive make has a lot of hard to resolve dependency issues and slow
incremental rebuilds. Our home-grown MSVC build system is hard to maintain for
developers not using Windows and runs tests serially. While these and other
issues could individually be addressed with incremental improvements, together
they seem best addressed by moving to a more modern build system.

After evaluating different build system choices, we chose to use meson, to a
good degree based on the adoption by other open source projects.

We decided that it's more realistic to commit a relatively early version of
the new build system and mature it in tree.

This commit adds an initial version of a meson based build system. It supports
building postgres on at least AIX, FreeBSD, Linux, macOS, NetBSD, OpenBSD,
Solaris and Windows (however only gcc is supported on aix, solaris). For
Windows/MSVC postgres can now be built with ninja (faster, particularly for
incremental builds) and msbuild (supporting the visual studio GUI, but
building slower).

Several aspects (e.g. Windows rc file generation, PGXS compatibility, LLVM
bitcode generation, documentation adjustments) are done in subsequent commits
requiring further review. Other aspects (e.g. not installing test-only
extensions) are not yet addressed.

When building on Windows with msbuild, builds are slower when using a visual
studio version older than 2019, because those versions do not support
MultiToolTask, required by meson for intra-target parallelism.

The plan is to remove the MSVC specific build system in src/tools/msvc soon
after reaching feature parity. However, we're not planning to remove the
autoconf/make build system in the near future. Likely we're going to keep at
least the parts required for PGXS to keep working around until all supported
versions build with meson.

Some initial help for postgres developers is at
https://wiki.postgresql.org/wiki/Meson

With contributions from Thomas Munro, John Naylor, Stone Tickle and others.

Author: Andres Freund <andres@anarazel.de>
Author: Nazir Bilal Yavuz <byavuz81@gmail.com>
Author: Peter Eisentraut <peter@eisentraut.org>
Reviewed-By: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Discussion: https://postgr.es/m/20211012083721.hvixq4pnh2pixr3j@alap3.anarazel.de
2022-09-21 22:37:17 -07:00
Michael Paquier
fbb5f54b67 Clear ps display of startup process at the end of recovery
If the ps display is not cleared at this point, the process could
continue displaying "recovering NNN" even if handling end-of-recovery
steps.  df9274a has tackled that by providing some information with the
end-of-recovery checkpoint but 7ff23c6 has nullified the effect of the
first commit.

Per a suggestion from Justin, just clear the ps display when we are done
with recovery, so as no incorrect information is displayed.  This may
get extended in the future, but for now restore the pre-7ff23c6
behavior.

Author: Justin Prysby
Discussion: https://postgr.es/m/20220913223954.GU31833@telsasoft.com
Backpatch-through: 15
2022-09-22 14:25:09 +09:00
Fujii Masao
2f636daac8 docs: Fix snapshot name in SET TRANSACTION docs.
Commit 6c2003f8a1 changed the snapshot names mentioned in
SET TRANSACTION docs, however, there was one place that
the commit missed updating the name.

Back-patch to all supported versions.

Author: Japin Li
Reviewed-by: Fujii Masao
Discussion: https://postgr.es/m/MEYP282MB1669BD4280044501165F8B07B64F9@MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM
2022-09-22 12:54:26 +09:00
Michael Paquier
14ff44f80c Used optimized linear search in more code paths
This commit updates two code paths to use pg_lfind32() introduced by
b6ef167 with TransactionId arrays:
- At the end of TransactionIdIsInProgress(), when checking for the case
of still running but overflowed subxids.
- XidIsConcurrent(), when checking for a serializable conflict.

These cases are less impactful than 37a6e5d, but a bit of
micro-benchmarking of this API shows that linear search speeds up by
~20% depending on the number of items involved (x86_64 and amd64 looked
at here).

Author: Nathan Bossart
Reviewed-by: Richard Guo, Michael Paquier
Discussion: https://postgr.es/m/20220901185153.GA783106@nathanxps13
2022-09-22 09:47:28 +09:00
Fujii Masao
9a6915257d psql: Improve tab-completion for MERGE.
Commit 7103ebb7aa added the tab-completion for MERGE accidentally
in the middle of that for LOCK TABLE. This commit fixes this issue.

This also adds some tab-completion for MERGE.

Back-patch to v15 where MERGE was introduced.

Author: Kotaro Kawamoto, Fujii Masao
Reviewed-by: Shinya Kato, Álvaro Herrera
Discussion: https://postgr.es/m/9f1ad2a87a58cd5e7d64f3993130958d@oss.nttdata.com
2022-09-22 09:25:29 +09:00
Andres Freund
661ee7bfc6 ci: windows: set error mode to not include SEM_NOGPFAULTERRORBOX
Cirrus defaults to SetErrorMode(SEM_NOGPFAULTERRORBOX | ...). That prevents
crash reporting from working unless binaries do SetErrorMode()
themselves. Furthermore, it appears that either python or, more likely, the C
runtime has a bug where SEM_NOGPFAULTERRORBOX can very occasionally *trigger*
a crash on process exit - which is hard to debug, given that it explicitly
prevents crash dumps from working...

Discussion: https://postgr.es/m/20220909235836.lz3igxtkcjb5w7zb%40awork3.anarazel.de
Backpatch: 15-, where CI was added
2022-09-21 17:16:34 -07:00
Thomas Munro
a3a3c1ea87 ci: Increase requested memory size.
CI builds recently started failing with:

"Memory size for 4.0 vCPU instance should be between 3840MiB and
26624MiB, while 2048MiB is requested."

Ok then, let's ask for 4G instead of 2G.

This may be due to a change in the type of instance used to work around
an outage, per:

https://twitter.com/cirrus_labs/status/1572657320093712384
2022-09-22 11:36:19 +12:00
Peter Geoghegan
aab06442d4 Harmonize lexer adjacent function parameter names.
Make sure that function declarations use names that exactly match the
corresponding names from function definitions for several "lexer
adjacent" backend functions.

These functions were missed by recent commits because they were obscured
by clang-tidy warnings about functions whose signature is directly under
the control of the lexer (flex seems to always generate function
declarations with unnamed parameters).  We probably can't fix most of
the warnings it generates for translation units that get built from .l
and .y files, but we can at least do this much.

Author: Peter Geoghegan <pg@bowt.ie>
Discussion: https://postgr.es/m/CAH2-WznJt9CMM9KJTMjJh_zbL5hD9oX44qdJ4aqZtjFi-zA3Tg@mail.gmail.com
2022-09-21 13:21:36 -07:00
Peter Eisentraut
e59a67fb8f Improve ICU option handling in CREATE DATABASE
We check that the ICU locale is only specified if the ICU locale
provider is selected.  But we did that too early.  We need to wait
until we load the settings of the template database, since that could
also set what the locale provider is.

Reported-by: Marina Polyakova <m.polyakova@postgrespro.ru>
Discussion: https://www.postgresql.org/message-id/9ba4cd1ea6ed6b7b15c0ff15e6f540cd@postgrespro.ru
2022-09-21 10:41:36 -04:00
Peter Eisentraut
2da8c4cff3 Tighten pg_get_object_address argument checking
For publication schemas (OBJECT_PUBLICATION_NAMESPACE) and user
mappings (OBJECT_USER_MAPPING), pg_get_object_address() checked the
array length of the second argument, but not of the first argument.
If the first argument was too long, it would just silently ignore
everything but the first argument.  Fix that by checking the length of
the first argument as well.

Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>
Discussion: https://www.postgresql.org/message-id/flat/caaef70b-a874-1088-92ef-5ac38269c33b%40enterprisedb.com
2022-09-21 09:42:35 -04:00
Alvaro Herrera
3d4e841a07
Improve some GUC description strings
It is not our usual style to use "we" in messages.  Also, remove some
noise words.  Backpatch to 15.

Noted by Kyotaro Horiguchi.

Discussion: https://postgr.es/m/20220914.111507.13049297635620898.horikyota.ntt@gmail.com
2022-09-21 12:29:38 +02:00
Amit Kapila
a932824dfe Pass Size as a 2nd argument for snprintf() in tablesync.c.
Previously the following snprintf() wrappers:

* ReplicationSlotNameForTablesync()
* ReplicationOriginNameForTablesync()

... used int as a second argument of snprintf() while the actual type of it
is size_t. Although it doesn't fail at present better replace it with Size
for consistency with the rest of the system.

Author: Aleksander Alekseev
Reviewed-By: Peter Smith
Discussion: https://postgr.es/m/CAHut%2BPsa8hhfSE6ozUK-ih7GkQziAVAf4f3bqiXEj2nQiu-43g%40mail.gmail.com
2022-09-21 10:20:37 +05:30
Amit Kapila
6971a839cc Improve some error messages.
It is not our usual style to use "we" in the error messages.

Author: Kyotaro Horiguchi
Reviewed-By: Amit Kapila
Discussion: https://postgr.es/m/20220914.111507.13049297635620898.horikyota.ntt@gmail.com
2022-09-21 09:43:59 +05:30
Andres Freund
3f0c901e74 Use \b in one more PG_TEST_EXTRA check, oversight in c3382a3c3c
Per off-list report from Thomas Munro.
2022-09-20 18:11:35 -07:00
Michael Paquier
ec3c9cc202 Add definition pg_attribute_aligned() for MSVC
Visual Studio 2015+ has support for a macro to control the alignement of
structures as of __declspec(align(#)), and this commit adds a definition
of pg_attribute_aligned() based on that.  It happens that this was
already used in the implementation of atomics for MSVC.  Note that there
is still no definition fo pg_attribute_packed(), so this does not impact
itemptr.h.

Author: James Coleman
Discussion: https://postgr.es/m/CAAaqYe-HbtZvR3msoMtk+hYW2S0e0OapzMW8icSMYTMA+mN8Aw@mail.gmail.com
2022-09-21 10:11:23 +09:00
Tom Lane
1c27d16e6e Revise tree-walk APIs to improve spec compliance & silence warnings.
expression_tree_walker and allied functions have traditionally
declared their callback functions as, say, "bool (*walker) ()"
to allow for variation in the declared types of the callback
functions' context argument.  This is apparently going to be
forbidden by the next version of the C standard, and the latest
version of clang warns about that.  In any case it's always
been pretty poor for error-detection purposes, so fixing it is
a good thing to do.

What we want to do is change the callback argument declarations to
be like "bool (*walker) (Node *node, void *context)", which is
correct so far as expression_tree_walker and friends are concerned,
but not change the actual callback functions.  Strict compliance with
the C standard would require changing them to declare their arguments
as "void *context" and then cast to the appropriate context struct
type internally.  That'd be very invasive and it would also introduce
a bunch of opportunities for future bugs, since we'd no longer have
any check that the correct sort of context object is passed by outside
callers or internal recursion cases.  Therefore, we're just going
to ignore the standard's position that "void *" isn't necessarily
compatible with struct pointers.  No machine built in the last forty
or so years actually behaves that way, so it's not worth introducing
bug hazards for compatibility with long-dead hardware.

Therefore, to silence these compiler warnings, introduce a layer of
macro wrappers that cast the supplied function name to the official
argument type.  Thanks to our use of -Wcast-function-type, this will
still produce a warning if the supplied function is seriously
incompatible with the required signature, without going as far as
the official spec restriction does.

This method fixes the problem without any need for source code changes
outside nodeFuncs.h/.c.  However, it is an ABI break because the
physically called functions now have names ending in "_impl".  Hence
we can only fix it this way in HEAD.  In the back branches, we'll have
to settle for disabling -Wdeprecated-non-prototype.

Discussion: https://postgr.es/m/CA+hUKGKpHPDTv67Y+s6yiC8KH5OXeDg6a-twWo_xznKTcG0kSA@mail.gmail.com
2022-09-20 18:03:22 -04:00