aboutsummaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAge
...
* Some cleanup for change of collate and ctype fields to type textPeter Eisentraut2022-02-02
| | | | | | | Some cleanup for commit 54637508f87bd5f07fb9406bac6b08240283be3b: Reformat pg_database.dat to reflect the new field order. Also update the corresponding example in bki.sgml. Reorder the way the fields are filled in dbcommands.c to correspond to the new order.
* Fix recovery conflict in 027_stream_regress.pl.Thomas Munro2022-02-02
| | | | | | | | | | | | | To avoid "ERROR: canceling statement due to conflict with recovery", as seen on a couple of slower build farm animals, crank max_standby_streaming_delay right up. In passing, adjust a configuration option that accidentally used a non-standard format (not a problem, but needlessly inconsistent). Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/CA%2BhUKGK65xVqNgsSPyrr2LEwtfUN%3DGfEuQ868hTC-mu0bFG42A%40mail.gmail.com
* Treat case of tab-completion keywords a bit more carefully.Tom Lane2022-02-01
| | | | | | | | | | | | | | | | | | | When completing keywords that are offered alongside names obtained from a query, preserve the user's choice of keyword case. This would have been messy to do before 02b8048ba, but now it's fairly simple. A complication is that we want keywords to be shown in upper case in any tab-completion menus that include both keywords and non-keywords, so we can't switch their case until enough has been typed that only keyword(s) remain to be chosen. Also, adjust some places where 02b8048ba thoughtlessly held over a previous choice to display keywords in lower case. (I think I got confused as to whether those words were keywords or variable names, but they're the former.) Dagfinn Ilmari Mannsåker and Tom Lane Discussion: https://postgr.es/m/8735l41ynm.fsf@wibble.ilmari.org
* Fix missing undefine in sort_template.hJohn Naylor2022-01-31
| | | | | | | | | | | All parameter macros are supposed to be undefined at the end of the header. ST_CHECK_FOR_INTERRUPTS was forgotten, so could affect later inclusions. Thomas Munro The patch set of which this is a part is discussed in https://www.postgresql.org/message-id/CA%2BhUKGLPommgNw-SVwUGkw1YmTDwmJ5vSKO0kFnZfbRHtNFW5w%40mail.gmail.com
* Simplify coding around path_contains_parent_reference().Tom Lane2022-01-31
| | | | | | | | | | | | | | | | | | | | | | Given the existing stipulation that path_contains_parent_reference() must only be invoked on canonicalized paths, we can simplify things in the wake of commit c10f830c5. It is now only possible to see ".." at the start of a relative path. That means we can simplify path_contains_parent_reference() itself quite a bit, and it makes the two existing outside call sites dead code, since they'd already checked that the path is absolute. We could now fold path_contains_parent_reference() into its only remaining caller path_is_relative_and_below_cwd(). But it seems better to leave it as a separately callable function, in case any extensions are using it. Also document the pre-existing requirement for path_is_relative_and_below_cwd's input to be likewise canonicalized. Shenhao Wang and Tom Lane Discussion: https://postgr.es/m/OSBPR01MB4214FA221FFE046F11F2AD74F2D49@OSBPR01MB4214.jpnprd01.prod.outlook.com
* Make canonicalize_path() more canonical.Tom Lane2022-01-31
| | | | | | | | | | | | | | | | | | | | | | | | | | Teach canonicalize_path() how to strip all unnecessary uses of "." and "..", replacing the previous ad-hoc code that got rid of only some such cases. In particular, we can always remove all such uses from absolute paths. The proximate reason to do this is that Windows rejects paths involving ".." in some cases (in particular, you can't put one in a symlink), so we ought to be sure we don't use ".." unnecessarily. Moreover, it seems like good cleanup on general principles. There is other path-munging code that could be simplified now, but we'll leave that for followup work. It is tempting to call this a bug fix and back-patch it. On the other hand, the misbehavior can only be reached if a highly privileged user does something dubious, so it's not unreasonable to say "so don't do that". And this patch could result in unexpected behavioral changes, in case anybody was expecting uses of ".." to stay put. So at least for now, just put it in HEAD. Shenhao Wang, editorialized a bit by me Discussion: https://postgr.es/m/OSBPR01MB4214FA221FFE046F11F2AD74F2D49@OSBPR01MB4214.jpnprd01.prod.outlook.com
* plperl: windows: Use Perl_setlocale on 5.28+, fixing compile failure.Andres Freund2022-01-30
| | | | | | | | | | | | | For older versions we need our own copy of perl's setlocale(), because it was not exposed (why we need the setlocale in the first place is explained in plperl_init_interp) . The copy stopped working in 5.28, as some of the used macros are not public anymore. But Perl_setlocale is available in 5.28, so use that. Author: Victor Wagner <vitus@wagner.pp.ru> Reviewed-By: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> Discussion: https://postgr.es/m/20200501134711.08750c5f@antares.wagner.home Backpatch: all versions
* Introduce pg_settings_get_flags() to find flags associated to a GUCMichael Paquier2022-01-31
| | | | | | | | | | | | | | | | | | | The most meaningful flags are shown, which are the ones useful for the user and for automating and extending the set of tests supported currently by check_guc. This script may actually be removed in the future, but we are not completely sure yet if and how we want to support the remaining sanity checks performed there, that are now integrated in the main regression test suite as of this commit. Thanks also to Peter Eisentraut and Kyotaro Horiguchi for the discussion. Bump catalog version. Author: Justin Pryzby Discussion: https://postgr.es/m/20211129030833.GJ17618@telsasoft.com
* psql: improve tab-complete's handling of variant SQL names.Tom Lane2022-01-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch improves tab completion's ability to deal with valid variant spellings of SQL identifiers. Notably: * Unquoted upper-case identifiers are now downcased as the backend would do, allowing them to be completed correctly. * Tab completion can now match identifiers that are quoted even though they don't need to be; for example "f<TAB> now completes to "foo" if that's the only available name. Previously, only names that require quotes would be offered. * Schema-qualified identifiers are now supported where SQL syntax allows it; many lesser-used completion rules neglected this. * Completion operations that refer back to some previously-typed name (for example, to complete names of columns belonging to a previously-mentioned table) now allow variant spellings of the previous name too. In addition, performance of tab completion queries has been improved for databases containing many objects, although you'd only be likely to notice with a heavily-loaded server. Authors of future tab-completion patches should note that this commit changes many details about how tab completion queries must be written: * Tab completion queries now deal in raw object names; do not use quote_ident(). * The name-matching restriction in a query must now be written as "outputcol LIKE '%s'", not "substring(outputcol,1,%d)='%s'". * The SchemaQuery mechanism has been extended so that it can handle queries that refer back to a previous name. Most completion queries that do that should be converted to SchemaQuery form. Only consider using a literal query if the previous name can never be schema-qualified. Don't use a literal query if the name-to-be-completed can validly be schema-qualified, either. * Use set_completion_reference() to specify which word is the previous name to consider, for either a SchemaQuery or a literal query. * If you want to offer some keywords in addition to a query result (for example, offer COLUMN in addition to column names after "ALTER TABLE t RENAME"), do not use the old hack of tacking the keywords on with UNION. Instead use the new QUERY_PLUS macros to write such keywords separately from the query proper. The "addon" macro arguments that used to be used for this purpose are gone. * If your query returns something that's not a SQL identifier (such as an attribute number or enum label), use the new QUERY_VERBATIM macros to prevent the result from incorrectly getting double-quoted. You may still need to use quote_literal in such a query, too. Tom Lane and Haiying Tang Discussion: https://postgr.es/m/a63cbd45e3884cf9b3961c2a6a95dcb7@G08CNEXMBPEKD05.g08.fujitsu.local
* Remove xloginsert.h from xlog.hAlvaro Herrera2022-01-30
| | | | | | | | | xlog.h is directly and indirectly #included in a lot of places. With this change, xloginsert.h is no longer unnecessarily included in the large number of them that don't need it. Author: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> Discussion: https://postgr.es/m/CALj2ACVe-W+WM5P44N7eG9C2_FmaeM8Dq5aCnD3fHt0Ba=WR6w@mail.gmail.com
* Fix failure to validate the result of select_common_type().Tom Lane2022-01-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Although select_common_type() has a failure-return convention, an apparent successful return just provides a type OID that *might* work as a common supertype; we've not validated that the required casts actually exist. In the mainstream use-cases that doesn't matter, because we'll proceed to invoke coerce_to_common_type() on each input, which will fail appropriately if the proposed common type doesn't actually work. However, a few callers didn't read the (nonexistent) fine print, and thought that if they got back a nonzero OID then the coercions were sure to work. This affects in particular the recently-added "anycompatible" polymorphic types; we might think that a function/operator using such types matches cases it really doesn't. A likely end result of that is unexpected "ambiguous operator" errors, as for example in bug #17387 from James Inform. Another, much older, case is that the parser might try to transform an "x IN (list)" construct to a ScalarArrayOpExpr even when the list elements don't actually have a common supertype. It doesn't seem desirable to add more checking to select_common_type itself, as that'd just slow down the mainstream use-cases. Instead, write a separate function verify_common_type that performs the missing checks, and add a call to that where necessary. Likewise add verify_common_type_from_oids to go with select_common_type_from_oids. Back-patch to v13 where the "anycompatible" types came in. (The symptom complained of in bug #17387 doesn't appear till v14, but that's just because we didn't get around to converting || to use anycompatible till then.) In principle the "x IN (list)" fix could go back all the way, but I'm not currently convinced that it makes much difference in real-world cases, so I won't bother for now. Discussion: https://postgr.es/m/17387-5dfe54b988444963@postgresql.org
* Fix comments about bgworker registration before MaxBackends initializationMichael Paquier2022-01-29
| | | | | | | | | | | | | | | | | | | Since 6bc8ef0b, InitializeMaxBackends() has used max_worker_processes instead of adapting MaxBackends to the number of background workers registered by modules loaded in shared_preload_libraries (at this time, bgworkers were only static, but gained dynamic capabilities as a matter of supporting parallel queries meaning that a control cap was necessary). Some comments referred to the past registration logic, making them confusing and incorrect, so fix these. Some of the out-of-core modules that could be loaded in this path sometimes like to manipulate dynamically some of the resource-related GUCs for their own needs, this commit adds a note about that. Author: Nathan Bossart Discussion: https://postgr.es/m/20220127181815.GA551692@nathanxps13
* vacuumlazy.c: Rename state field for consistency.Peter Geoghegan2022-01-28
| | | | | Rename pages_removed to removed_pages, for consistency with nearby vacrel fields.
* Fix incorrect memory context switch in COPY TO executionMichael Paquier2022-01-29
| | | | | | | | | | | | | | | | | | | | c532d15 has split the logic of COPY commands into multiple files, one change being to move the internals of BeginCopy() to BeginCopyTo(). Originally the code was written so as we'd switch back-and-forth between the current execution memory context and the dedicated memory context for the COPY command, and this refactoring has introduced an extra switch to the current memory context from the COPY context once BeginCopyTo() is done with the past logic coming from BeginCopy(). The code was correctly doing the analyze, rewrite and planning phases in the COPY context, but it was not assigning "copy_file" (FILE* used when copying to a source file) and "filename" in the COPY context, making the COPY status data inconsistent. Author: Bharath Rupireddy Reviewed-by: Japin Li Discussion: https://postgr.es/m/CALj2ACWvVa69foi9jhHFY=2BuHxAoYboyE+vXQTARwxZcJnVrQ@mail.gmail.com Backpatch-through: 14
* Add bbstreamer_gzip.c to Mkvcbuild.pm.Robert Haas2022-01-28
| | | | | | | Also add a note to src/bin/pg_basebackup/Makefile to try to reduce the chances of future mistakes of this type. Per bowerbird.
* Tab-complete ALTER PUBLICATION ADD TABLE with list of tablesAlvaro Herrera2022-01-28
| | | | | | | This has been posted as part of the column-list feature for logical replication since [1], but it's not really related to that. [1] https://postgr.es/m/202112131747.cmlstdewm4kh@alvherre.pgsql
* Remove superfluous variable.Robert Haas2022-01-28
| | | | | | Jeevan Ladhe Discussion: http://postgr.es/m/CAOgcT0PJpOiafsmZfGZRLGK1WUqZwYdjFWRwgZTVDQHCCwO-EQ@mail.gmail.com
* Move the code to archive files via the shell to a separate file.Robert Haas2022-01-28
| | | | | | | | This is preparatory work for allowing more extensibility in this area. Nathan Bossart Discussion: http://postgr.es/m/668D2428-F73B-475E-87AE-F89D67942270@amazon.com
* Adjust server-side backup to depend on pg_write_server_files.Robert Haas2022-01-28
| | | | | | | | | | | I had made it depend on superuser, but that seems clearly inferior. Also document the permissions requirement in the straming replication protocol section of the documentation, rather than only in the section having to do with pg_basebackup. Idea and patch from Dagfinn Ilmari Mannsåker. Discussion: http://postgr.es/m/87bkzw160u.fsf@wibble.ilmari.org
* pg_basebackup: Cleaner handling when compression is multiply specified.Robert Haas2022-01-28
| | | | | | | | | | Tushar Ahuja discovered that if you use both --compress and --gzip, or --compress multiple times, the last instance of one of these options doesn't in all cases overwrite the compression level set by an earlier option. That's not a serious bug, but it also has nothing to recommend it. Repair. Discussion: http://postgr.es/m/CA+TgmoZfP=rsZB_9vDGfhuNgSu_M_09UWu8SjvsP65y_1pQFCg@mail.gmail.com
* Fix mistakes in commit d45099425eb19e420433c9d81d354fe585f4dbd6.Robert Haas2022-01-28
| | | | | | | | | | I intended to include a change to the "skip" count in the test case, but it didn't get folded into the commit. Do that now, so that non-zlib builds don't break. The new file bbstreamer_gzip.c needs <unistd.h> to avoid complaints about dup() not having a prototype, as per buildfarm returns.
* Allow server-side compression to be used with -Fp.Robert Haas2022-01-28
| | | | | | | | | | | If you have a low-bandwidth connection between the client and the server, it's reasonable to want to compress on the server side but then decompress and extract the backup on the client side. This commit allows you do to do just that. Dipesh Pandit, with minor and mostly cosmetic changes by me. Discussion: http://postgr.es/m/CAN1g5_HiSh8ajUMd4ePtGyCXo89iKZTzaNyzP_qv1eJbi4YHXA@mail.gmail.com
* Add HEADER support to COPY text formatPeter Eisentraut2022-01-28
| | | | | | | | | | The COPY CSV format supports the HEADER option to output a header line. This patch adds the same option to the default text format. On input, the HEADER option causes the first line to be skipped, same as with CSV. Author: Rémi Lapeyre <remi.lapeyre@lenstra.fr> Discussion: https://www.postgresql.org/message-id/flat/CAF1-J-0PtCWMeLtswwGV2M70U26n4g33gpe1rcKQqe6wVQDrFA@mail.gmail.com
* Add some const decorationsPeter Eisentraut2022-01-28
|
* Fix typo in comment.Etsuro Fujita2022-01-28
|
* Prevent memory context logging from sending log message to connected client.Fujii Masao2022-01-28
| | | | | | | | | | | | | | | | | | When pg_log_backend_memory_contexts() is executed, the target backend should use LOG_SERVER_ONLY to log its memory contexts, to prevent them from being sent to its connected client regardless of client_min_messages. But previously the backend unexpectedly used LOG to log the message "logging memory contexts of PID %d" and it could be sent to the client. This is a bug in memory context logging. To fix the bug, this commit changes that message so that it's logged with LOG_SERVER_ONLY. Back-patch to v14 where pg_log_backend_memory_contexts() was added. Author: Fujii Masao Reviewed-by: Bharath Rupireddy, Atsushi Torikoshi Discussion: https://postgr.es/m/82c12f36-86f7-5e72-79af-7f5c37f6cad7@oss.nttdata.com
* Specify --host in 027_stream_regress.pl's pg_regress invocation.Andres Freund2022-01-27
| | | | | | | | | | | | | | | | | The invocation of pg_regress in 027_stream_regress.pl didn't specify the host. It ends up working on most systems because of connection defaults. However, on windows it makes the test very slow unless PG_TEST_USE_UNIX_SOCKETS is used. The problem is that windows resolves "localhost" to ::0, 127.0.0.1, the server started only listens on 127.0.0.1. On windows refused TCP connections are internally retried a few times, with back-off between tries, taking at least 2 seconds. Noticed while investigating a complaint about the test's slow speed by Andrew Dunstan. Discussion: https://postgr.es/m/20220127220351.kyp3bdaukfytmoqx@alap3.anarazel.de
* Avoid referencing Z_DEFAULT_COMPRESSION outside HAVE_LIBZ.Robert Haas2022-01-27
| | | | | | Because that's bad. Discussion: http://postgr.es/m/20220127174545.GV23027@telsasoft.com
* pg_basebackup: Add a dummy return to bbsink_gzip_new().Robert Haas2022-01-27
| | | | | | | | Apparently, this is needed to avoid warnings on MVCC. David Rowley Discussion: http://postgr.es/m/CAApHDvosHkgyo_PZs7CSB4Kgs2ey4FdmFpcK0N_QOci9DJ=wnw@mail.gmail.com
* Fix ordering of XIDs in ProcArrayApplyRecoveryInfoTomas Vondra2022-01-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 8431e296ea reworked ProcArrayApplyRecoveryInfo to sort XIDs before adding them to KnownAssignedXids. But the XIDs are sorted using xidComparator, which compares the XIDs simply as uint32 values, not logically. KnownAssignedXidsAdd() however expects XIDs in logical order, and calls TransactionIdFollowsOrEquals() to enforce that. If there are XIDs for which the two orderings disagree, an error is raised and the recovery fails/restarts. Hitting this issue is fairly easy - you just need two transactions, one started before the 4B limit (e.g. XID 4294967290), the other sometime after it (e.g. XID 1000). Logically (4294967290 <= 1000) but when compared using xidComparator we try to add them in the opposite order. Which makes KnownAssignedXidsAdd() fail with an error like this: ERROR: out-of-order XID insertion in KnownAssignedXids This only happens during replica startup, while processing RUNNING_XACTS records to build the snapshot. Once we reach STANDBY_SNAPSHOT_READY, we skip these records. So this does not affect already running replicas, but if you restart (or create) a replica while there are transactions with XIDs for which the two orderings disagree, you may hit this. Long-running transactions and frequent replica restarts increase the likelihood of hitting this issue. Once the replica gets into this state, it can't be started (even if the old transactions are terminated). Fixed by sorting the XIDs logically - this is fine because we're dealing with normal XIDs (because it's XIDs assigned to backends) and from the same wraparound epoch (otherwise the backends could not be running at the same time on the primary node). So there are no problems with the triangle inequality, which is why xidComparator compares raw values. Investigation and root cause analysis by Abhijit Menon-Sen. Patch by me. This issue is present in all releases since 9.4, however releases up to 9.6 are EOL already so backpatch to 10 only. Reviewed-by: Abhijit Menon-Sen Reviewed-by: Alvaro Herrera Backpatch-through: 10 Discussion: https://postgr.es/m/36b8a501-5d73-277c-4972-f58a4dce088a%40enterprisedb.com
* pg_basebackup: Fix a couple of recently-introduced bugs.Robert Haas2022-01-27
| | | | | | | | | | | | | | The server expects the compression level to be between 1 and 9, but Z_DEFAULT_COMPRESSION is -1, so we must not try to send that value to the server. Because pg_basebackup's -R option is implemented on the client side, it can't be used in combination with a backup target. Error out if someone tries that, instead of silently ignoring the option. Both issues were reported by Tushar Ahuja; patch by me. Discussion: http://postgr.es/m/CA+TgmoaMwgdx8HxBjF8hmbohVvPL_0H5LqNrSq0uU+7BKp_Q2A@mail.gmail.com
* Improve msys2 detection for TAP testsAndrew Dunstan2022-01-27
| | | | | | | | Perl instances on some msys toolchains (e.g. UCRT64) have their configured osname set to 'MSWin32' rather than 'msys'. The test for the msys2 platform is adjusted accordingly. Backpatch to release 14.
* psql: Add tab completion for ALTER COLLATION / REFRESH VERSIONPeter Eisentraut2022-01-27
| | | | | This was forgotten when this command form was added (eccfef81e1f73ee41f1d8bfe4fa4e80576945048).
* Change collate and ctype fields to type textPeter Eisentraut2022-01-27
| | | | | | | | | | | | | | | | | | | This changes the data type of the catalog fields datcollate, datctype, collcollate, and collctype from name to text. There wasn't ever a really good reason for them to be of type name; presumably this was just carried over from when they were fixed-size fields in pg_control, first into the corresponding pg_database fields, and then to pg_collation. The values are not identifiers or object names, and we don't ever look them up that way. Changing to type text saves space in the typical case, since locale names are typically only a few bytes long. But it is also possible that an ICU locale name with several customization options appended could be longer than 63 bytes, so this also enables that case, which was previously probably broken. Reviewed-by: Julien Rouhaud <rjuju123@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/5e756dd6-0e91-d778-96fd-b1bcb06c161a@2ndquadrant.com
* On sparc64+ext4, suppress test failures from known WAL read failure.Noah Misch2022-01-26
| | | | | | | | | | Buildfarm members kittiwake, tadarida and snapper began to fail frequently when commits 3cd9c3b921977272e6650a5efbeade4203c4bca2 and f47ed79cc8a0cfa154dc7f01faaf59822552363f added tests of concurrency, but the problem was reachable before those commits. Back-patch to v10 (all supported versions). Discussion: https://postgr.es/m/20220116210241.GC756210@rfd.leadboat.com
* Fix pg_hba_file_rules for authentication method certMagnus Hagander2022-01-26
| | | | | | | | | | | For authentication method cert, clientcert=verify-full is implied. But the pg_hba_file_rules entry would incorrectly show clientcert=verify-ca. Per bug #17354 Reported-By: Feike Steenbergen Reviewed-By: Jonathan Katz Backpatch-through: 12
* Tidy up a few cosmetic issues related to pg_basebackup.Robert Haas2022-01-25
| | | | | | | | | | | | | | | | | Commit 0ad8032910d5eb8efd32867c45b6a25c85e60f50 failed to update the pg_basebackup documentation to mention that "client-" or "server-" can now be prepended to the compression method name. Fix it there, and also in the --help output that you get from running the binary. Also in the documentation, there's an old issue that the arguments to --checkpoint shouldn't be marked as parameters, because "fast" and "spread" are literal strings. Fix that too. Dagfinn Ilmari Mannsåker, partly as per a report from Shinoda Noriyoshi. Discussion: http://postgr.es/m/PH7PR84MB1885C1CF433057807551172BEE5F9@PH7PR84MB1885.NAMPRD84.PROD.OUTLOOK.COM
* Consider parallel awareness when removing single-child AppendsDavid Rowley2022-01-25
| | | | | | | | | | | | | | | | | 8edd0e794 added some code to remove Append and MergeAppend nodes when they contained a single child node. As it turned out, this was unsafe to do when the Append/MergeAppend was parallel_aware and the child node was not. Removing the Append/MergeAppend, in this case, could lead to the child plan being called multiple times by parallel workers when it was unsafe to do so. Here we fix this by just not removing the Append/MergeAppend when the parallel_aware flag of the parent and child node don't match. Reported-by: Yura Sokolov Bug: #17335 Discussion: https://postgr.es/m/b59605fecb20ba9ea94e70ab60098c237c870628.camel%40postgrespro.ru Backpatch-through: 12, where 8edd0e794 was first introduced
* Improve errors related to incorrect TLI on checkpoint record replayMichael Paquier2022-01-25
| | | | | | | | | | | | | | WAL replay would cause a hard crash if the timeline expected by a XLOG_END_OF_RECOVERY, a XLOG_CHECKPOINT_ONLINE, or a XLOG_CHECKPOINT_SHUTDOWN record is not the same as the timeline being replayed, using the same error message for all three of them. This commit changes those error messages to use different wordings, adapted to each record type, which is useful when it comes to the debugging of an issue in this area. Author: Amul Sul Reviewed-by: Nathan Bossart, Robert Haas Discussion: https://postgr.es/m/CAAJ_b97i1ZerYC_xW6o_AiDSW5n+sGi8k91Yc8KS8bKWKxjqwQ@mail.gmail.com
* Fix various typos, grammar and code style in comments and docsMichael Paquier2022-01-25
| | | | | | | | | This fixes a set of issues that have accumulated over the past months (or years) in various code areas. Most fixes are related to some recent additions, as of the development of v15. Author: Justin Pryzby Discussion: https://postgr.es/m/20220124030001.GQ23027@telsasoft.com
* Unbreak pg_verifybackup/t/008_untar.pl on msysAndrew Dunstan2022-01-24
| | | | | Commit 0ad8032910 contains the same pattern fixed in commit 4f0bcc7350. Apply the same fix.
* Add tests of the CREATEROLE attributeAndrew Dunstan2022-01-24
| | | | | | | | | | The current regression tests do not contain much testing of CREATEROLE. This patch, extracted from a larger patch set to modify how that feature works, remedies that omission. Author: Mark Dilger Discussion: https://postgr.es/m/D9065DFB-56DB-4E89-A73E-DB8CC2C746C6@enterprisedb.com
* Fix limitations on what SQL commands can be issued to a walsender.Tom Lane2022-01-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In logical replication mode, a WalSender is supposed to be able to execute any regular SQL command, as well as the special replication commands. Poor design of the replication-command parser caused it to fail in various cases, notably: * semicolons embedded in a command, or multiple SQL commands sent in a single message; * dollar-quoted literals containing odd numbers of single or double quote marks; * commands starting with a comment. The basic problem here is that we're trying to run repl_scanner.l across the entire input string even when it's not a replication command. Since repl_scanner.l does not understand all of the token types known to the core lexer, this is doomed to have failure modes. We certainly don't want to make repl_scanner.l as big as scan.l, so instead rejigger stuff so that we only lex the first token of a non-replication command. That will usually look like an IDENT to repl_scanner.l, though a comment would end up getting reported as a '-' or '/' single-character token. If the token is a replication command keyword, we push it back and proceed normally with repl_gram.y parsing. Otherwise, we can drop out of exec_replication_command() without examining the rest of the string. (It's still theoretically possible for repl_scanner.l to fail on the first token; but that could only happen if it's an unterminated single- or double-quoted string, in which case you'd have gotten largely the same error from the core lexer too.) In this way, repl_gram.y isn't involved at all in handling general SQL commands, so we can get rid of the SQLCmd node type. (In the back branches, we can't remove it because renumbering enum NodeTag would be an ABI break; so just leave it sit there unused.) I failed to resist the temptation to clean up some other sloppy coding in repl_scanner.l while at it. The only externally-visible behavior change from that is it now accepts \r and \f as whitespace, same as the core lexer. Per bug #17379 from Greg Rychlewski. Back-patch to all supported branches. Discussion: https://postgr.es/m/17379-6a5c6cfb3f1f5e77@postgresql.org
* Server-side gzip compression.Robert Haas2022-01-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | pg_basebackup's --compression option now lets you write either "client-gzip" or "server-gzip" instead of just "gzip" to specify where the compression should be performed. If you write simply "gzip" it's taken to mean "client-gzip" unless you also use --target, in which case it is interpreted to mean "server-gzip", because that's the only thing that makes any sense in that case. To make this work, the BASE_BACKUP command now takes new COMPRESSION and COMPRESSION_LEVEL options. At present, pg_basebackup cannot decompress .gz files, so server-side compression will cause a failure if (1) -Ft is not used or (2) -R is used or (3) -D- is used without --no-manifest. Along the way, I removed the information message added by commit 5c649fe153367cdab278738ee4aebbfd158e0546 which occurred if you specified no compression level and told you that the default level had been used instead. That seemed like more output than most people would want. Also along the way, this adds a check to the server for unrecognized base backup options. This repairs a bug introduced by commit 0ba281cb4bf9f5f65529dfa4c8282abb734dd454. This commit also adds some new test cases for pg_verifybackup. They take a server-side backup with and without compression, and then extract the backup if we have the OS facilities available to do so, and then run pg_verifybackup on the extracted directory. That is a good test of the functionality added by this commit and also improves test coverage for the backup target patch (commit 3500ccc39b0dadd1068a03938e4b8ff562587ccc) and for pg_verifybackup itself. Patch by me, with a bug fix by Jeevan Ladhe. The patch set of which this is a part has also had review and/or testing from Tushar Ahuja, Suraj Kharage, Dipesh Pandit, and Mark Dilger. Discussion: http://postgr.es/m/CA+Tgmoa-ST7fMLsVJduOB7Eub=2WjfpHS+QxHVEpUoinf4bOSg@mail.gmail.com
* pg_upgrade: Preserve database OIDs.Robert Haas2022-01-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 9a974cbcba005256a19991203583a94b4f9a21a9 arranged to preserve relfilenodes and tablespace OIDs. For similar reasons, also arrange to preserve database OIDs. One problem is that, up until now, the OIDs assigned to the template0 and postgres databases have not been fixed. This could be a problem when upgrading, because pg_upgrade might try to migrate a database from the old cluster to the new cluster while keeping the OID and find a different database with that OID, resulting in a failure. If it finds a database with the same name and the same OID that's OK: it will be dropped and recreated. But the same OID and a different name is a problem. To prevent that, fix the OIDs for postgres and template0 to specific values less than 16384. To avoid running afoul of this rule, these values should not be changed in future releases. It's not a problem that these OIDs aren't fixed in existing releases, because the OIDs that we're assigning here weren't used for either of these databases in any previous release. Thus, there's no chance that an upgrade of a cluster from any previous release will collide with the OIDs we're assigning here. And going forward, the OIDs will always be fixed, so the only potential collision is with a system database having the same name and the same OID, which is OK. This patch lets users assign a specific OID to a database as well, provided however that it can't be less than 16384. I (rhaas) thought it might be better not to expose this capability to users, but the consensus was otherwise, so the syntax is documented. Letting users assign OIDs below 16384 would not be OK, though, because a user-created database with a low-numbered OID might collide with a system-created database in a future release. We therefore prohibit that. Shruthi KC, based on an earlier patch from Antonin Houska, reviewed and with some adjustments by me. Discussion: http://postgr.es/m/CA+TgmoYgTwYcUmB=e8+hRHOFA0kkS6Kde85+UNdon6q7bt1niQ@mail.gmail.com Discussion: http://postgr.es/m/CAASxf_Mnwm1Dh2vd5FAhVX6S1nwNSZUB1z12VddYtM++H2+p7w@mail.gmail.com
* Unbreak pg_basebackup/t/010_pg_basebackup.pl on msysAndrew Dunstan2022-01-24
| | | | | | | Once again we ran foul of the rather baroque msys2 path translation rules. The cure as in many cases is to do the translation ourselves. Discussion: https://postgr.es/m/CA+TgmoZU+1yj8TZ8PZrPHxPmr6Wz84V2RfZnsd5HnZugYtqZng@mail.gmail.com
* Remember to reset yy_start state when firing up repl_scanner.l.Tom Lane2022-01-24
| | | | | | | | | | | | | | | Without this, we get odd behavior when the previous cycle of lexing exited in a non-default exclusive state. Every other copy of this code is aware that it has to do BEGIN(INITIAL), but repl_scanner.l did not get that memo. The real-world impact of this is probably limited, since most replication clients would abandon their connection after getting a syntax error. Still, it's a bug. This mistake is old, so back-patch to all supported branches. Discussion: https://postgr.es/m/1874781.1643035952@sss.pgh.pa.us
* pg_basebackup: Skip a few more fsyncs if --no-sync is specified.Andres Freund2022-01-23
| | | | | | | This is mostly interesting for running the regression tests on machines with slow / overloaded IO. Discussion: https://postgr.es/m/20220119041646.rhuo3youiqxqjmo2@alap3.anarazel.de
* pg_dump: avoid useless query in binary_upgrade_set_type_oids_by_type_oidTom Lane2022-01-23
| | | | | | | | | | | Commit 6df7a9698 wrote appendPQExpBuffer where it should have written printfPQExpBuffer. This resulted in re-issuing the previous query along with the desired one, which very accidentally had no negative consequences except for some wasted cycles. Back-patch to v14 where that came in. Discussion: https://postgr.es/m/1714711.1642962663@sss.pgh.pa.us
* Clean up recent Coverity complaints.Tom Lane2022-01-23
| | | | | | | | | | | | | | Commit 5c649fe15 introduced a memory leak into pg_basebackup's parse_compress_options. (I simplified nearby code while at it.) Commit 9a974cbcb introduced a memory leak into pg_dump's binary_upgrade_set_pg_class_oids. Coverity also complained about a call of SnapBuildProcessChange that ignored the result, unlike every other call of that function. This is evidently intentional, so add a (void) cast to indicate that. (It's also old, dating to b89e15105; I suppose the reason it showed up now is 7a5f6b474's recent rearrangement of nearby code.)
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-05 09:32:56 +0000