aboutsummaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAge
* Fix misleading comment for get_cheapest_group_keys_orderDavid Rowley2022-09-20
| | | | | | | | | | | | | | | | | The header comment for get_cheapest_group_keys_order() claimed that the output arguments were set to a newly allocated list which may be freed by the calling function, however, this was not always true as the function would simply leave these arguments untouched in some cases. This tripped me up when working on 1349d2790 as I mistakenly assumed I could perform a list_concat with the output parameters. That turned out bad due to list_concat modifying the original input lists. In passing, make it more clear that the number of distinct values is important to reduce tiebreaks during sorts. Also, explain what the n_preordered parameter means. Backpatch-through: 15, where get_cheapest_group_keys_order was introduced.
* Fix out-dated comment in preprocess_groupclause()David Rowley2022-09-20
| | | | | | | | The comment claimed we don't consider other orders of the GROUP BY clause, but this is no longer true as of db0d67db2. Discussion: https://postgr.es/m/CAApHDvq65=9Ro+hLX1i9ugWEiNDvHrBibAO7ARcTnf38_JE+UQ@mail.gmail.com Backpatch-through: 15, where db0d67db2 was introduced.
* Remove various duplicated wordsDavid Rowley2022-09-20
| | | | | Author: Justin Pryzby Discussion: https://postgr.es/m/20220919111000.GW31833@telsasoft.com
* Fix icu tests with C localePeter Eisentraut2022-09-19
| | | | | | | | Similar to 1e08576691bf1a25c0e28745e5e800c44f2a1c76, but for the icu test suite. Reported-by: Christoph Berg <myon@debian.org> Discussion: https://www.postgresql.org/message-id/YyWeU61YMFwjVdxE@msg.df7cb.de
* Make ALTER DEFAULT PRIVILEGES require privileges, not membership.Robert Haas2022-09-19
| | | | | | | | | | | | | | | | | | | | | | | | If role A is a direct or indirect member of role B but does not inherit B's privileges (because at least one relevant grant was created WITH INHERIT FALSE) then A should not be permitted to bypass privilege checks that require the privileges of B. For example, A can't change the privileges of objects owned by B, nor can A drop those objects. However, up until now, it's been possible for A to change default privileges for role B. That doesn't seem to be correct, because a non-inherited role grant is only supposed to permit you to assume the identity of the granted role via SET ROLE, and should not otherwise permit you to exercise the privileges of that role. Most places followed that rule, but this case was an exception. This could be construed as a security vulnerability, but it does not seem entirely clear cut, since older branches were fuzzy about the distinction between is_member_of_role() and has_privs_of_role() in a number of other ways as well. Because of this, and because user-visible behavior changes in minor releases are to be avoided whenever possible, no back-patch. Discussion: http://postgr.es/m/CA+TgmobG_YUP06R_PM_2Z7wR0qv_52gQPHD8CYXbJva0cf0E+A@mail.gmail.com
* walmethods.c/h: Make WalWriteMethod more object-oriented.Robert Haas2022-09-19
| | | | | | | | | | | | | | | | | | | | | | Normally when we use object-oriented programming techniques, we provide a pointer to an object and then some way of looking up the associated table of callbacks, but walmethods.c/h took the alternative approach of providing only a pointer to the table of callbacks and thus imposed the artificial restriction that there could only ever be one object of each type, so that the callbacks could find it via a global variable. That doesn't seem like the right idea, so revise the approach. Each callback which does not already have an argument of type Walfile * now takes a pointer to the relevant WalWriteMethod * so that these callbacks need not rely on there being only one object of each type. Freeing a WalWriteMethod is now performed via a callback provided for that purpose rather than requiring the caller to know which WAL method they want to free. Discussion: http://postgr.es/m/CA+TgmoZS0Kw98fOoAcGz8B9iDhdqB4Be4e=vDZaJZ5A-xMYBqA@mail.gmail.com
* Future-proof the recursion inside ExecShutdownNode().Tom Lane2022-09-19
| | | | | | | | | | | | | | | | | | | | | | | The API contract for planstate_tree_walker() callbacks is that they take a PlanState pointer and a context pointer. Somebody figured they could save a couple lines of code by ignoring that, and passing ExecShutdownNode itself as the walker even though it has but one argument. Somewhat remarkably, we've gotten away with that so far. However, it seems clear that the upcoming C2x standard means to forbid such cases, and compilers that actively break such code likely won't be far behind. So spend the extra few lines of code to do it honestly with a separate walker function. In HEAD, we might as well go further and remove ExecShutdownNode's useless return value. I left that as-is in back branches though, to forestall complaints about ABI breakage. Back-patch, with the thought that this might become of practical importance before our stable branches are all out of service. It doesn't seem to be fixing any live bug on any currently known platform, however. Discussion: https://postgr.es/m/208054.1663534665@sss.pgh.pa.us
* walmethods.c/h: Make Walfile a struct, rather than a void *Robert Haas2022-09-19
| | | | | | | | | | | | | | | | | | | | | | | This makes the curent file position and pathname visible in a generic way, so we no longer need current_walfile_name global variable or the get_current_pos() method. Since that purported to be able to fail but never actually did, this also lets us get rid of some unnecessary error-handling code. One risk of this change is that the get_current_pos() method previously cleared the error indicator, and that will no longer happen with the new approach. I looked for a way that this could cause problems and did not find one. The previous code was confused about whether "Walfile" was the implementation-dependent structure representing a WAL file or whether it was a pointer to that stucture. Some of the code used it one way, and some in the other. The compiler tolerated that because void * is interchangeable with void **, but now that Walfile is a struct, it's necessary to be consistent. Hence, some references to "Walfile" have been converted to "Walfile *". Discussion: http://postgr.es/m/CA+TgmoZS0Kw98fOoAcGz8B9iDhdqB4Be4e=vDZaJZ5A-xMYBqA@mail.gmail.com
* Add missing serial commasPeter Eisentraut2022-09-19
|
* Fix typos.Amit Kapila2022-09-19
| | | | | Author: Hou Zhijie and Zhang Mingli Discussion: https://postgr.es/m/OS0PR01MB57162559C01FE2848C12E8F7944D9@OS0PR01MB5716.jpnprd01.prod.outlook.com
* Fix typos referring to PGPROCJohn Naylor2022-09-19
| | | | | | | Japin Li Reviewed by Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/MEYP282MB1669459813B36FB5EAA38434B6499@MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM
* Harmonize missed reorderbuffer parameter names.Peter Geoghegan2022-09-18
| | | | | | | | The function ReorderBufferCommitChild() was overlooked by initial work from commit 035ce1fe. Author: Peter Geoghegan <pg@bowt.ie> Discussion: https://postgr.es/m/CAH2-WzkhzFESnRo+VaGqyEZuzc33Dw09BdZBVmW896Sa22ci_A@mail.gmail.com
* Remove unused argument "isSlice" from transformAssignmentSubscripts()Michael Paquier2022-09-18
| | | | | | | | | | | | | Since c7aba7c, the transform method used during parse analysis of a subcripting construct has moved from transformAssignmentSubscripts() to the per-type transform method (arrays or arbitrary types) the step that checks for slicing support, but transformAssignmentSubscripts() has kept traces of it. Removing it simplifies the code, so let's clean up all that. Author: Zhang Mingli Reviewed-by: Richard Guo Discussion: https://postgr.es/m/0d7041ac-c704-48ad-86fd-e05feddf08ed@Spark
* Harmonize reorderbuffer parameter names.Peter Geoghegan2022-09-17
| | | | | | | | | | | | | | | Make reorderbuffer.h function declarations consistently use named parameters. Also make sure that the declarations use names that match corresponding names from function definitions in reorderbuffer.c. This makes the definitions easier to follow, especially in the case of functions that happen to have adjoining arguments of the same type. This patch was written with help from clang-tidy. Specifically, its "readability-inconsistent-declaration-parameter-name" check and its "readability-named-parameter" check were used. Author: Peter Geoghegan <pg@bowt.ie> Discussion: https://postgr.es/m/3955318.1663377656@sss.pgh.pa.us
* Make check_usermap() parameter names consistent.Peter Geoghegan2022-09-17
| | | | | | | | | | | The function has a bool argument named "case_insensitive", but that was spelled "case_sensitive" in the declaration. Make them consistent now to avoid confusion in the future. Author: Peter Geoghegan <pg@bowt.ie> Reviewed-By: Michael Paquiër <michael@paquier.xyz> Discussion: https://postgr.es/m/CAH2-WznJt9CMM9KJTMjJh_zbL5hD9oX44qdJ4aqZtjFi-zA3Tg@mail.gmail.com Backpatch: 10-
* Include c.h instead of postgres.h in src/port/*p{read,write}*.cAndres Freund2022-09-17
| | | | | | | | Frontend code shouldn't include postgres.h. Some files in src/port/ need to include postgres.h/postgres_fe.h, but these files don't. Discussion: https://postgr.es/m/20220915022626.5xx3ccgkzpkqw5mq@awork3.anarazel.de Backpatch: 12-, where 3fd2a7932ef introduced (some) of these files
* Remove DLLTOOL, DLLWRAP from configure / Makefile.global.inAndres Freund2022-09-17
| | | | | | We got rid of the need for them in 4f5f485d10c and 846e91e0223. Discussion: https://postgr.es/m/20220915022626.5xx3ccgkzpkqw5mq@awork3.anarazel.de
* pgstat: Create memory contexts below TopMemoryContextAndres Freund2022-09-17
| | | | | | | | | | | | | | | So far they were created below CacheMemoryContext. However, that's not guaranteed to exist in all situations, leading to memory contexts created as top-level contexts. There isn't actually a good reason anymore to create them below CacheMemoryContext, so just creating them below TopMemoryContext seems the best approach. Reported-by: Reid Thompson <reid.thompson@crunchydata.com> Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com> Reviewed-by: Andres Freund <andres@anarazel.de> Author: "Drouvot, Bertrand" <bdrouvot@amazon.com> Discussion: https://postgr.es/m/b948b729-42fe-f88c-2f4a-0e65d84c049b@amazon.com Backpatch: 15-
* Fix huge_pages on WindowsMichael Paquier2022-09-17
| | | | | | | | | | | | | | | | | | | Since Windows 10 1703, it is additionally necessary to pass a flag called FILE_MAP_LARGE_PAGES to MapViewOfFile() to enable large pages at map time. This flag is ignored on older versions of Windows, where large pages should still be able to work properly without setting it. Note that the flag would be set only for binaries that knew about it at compile-time, which should be more or less all the Windows environments these days. Since 495ed0e, Windows 10 is the minimum version of Windows supported by Postgres, making this change easy to reason about on HEAD. Per discussion, no backpatch is done for the moment. Reported-by: Okano Naoki Author: Thomas Munro Reviewed-by: Tom Lane, Michael Paquier, Julien Rouhaud Discussion: https://postgr.es/m/17448-0a96583a67edb1f7@postgresql.org
* Message style improvementsPeter Eisentraut2022-09-17
|
* Fix race condition in stats.sql added in 5264add7847Andres Freund2022-09-16
| | | | | | | | | | | | | | | Very occasionally the stats test failed due to the number of sessions not being updated yet. Likely this requires that there is contention on the database's stats entry. Solve this by forcing pending stats to be flushed before fetching the stats. I verified that there are no other test failures after making pgstat_report_stat() only flush stats when force = true. Per message from Tom Lane and buildfarm member crake. Discussion: https://postgr.es/m/3428246.1663271992@sss.pgh.pa.us Backpatch: 15-, where 5264add7847 added the test
* Improve plpgsql's ability to handle arguments declared as RECORD.Tom Lane2022-09-16
| | | | | | | | | | | | | | | | | Treat arguments declared as RECORD as if that were a polymorphic type (which it is, sort of), in that we substitute the actual argument type while forming the function cache lookup key. This allows the specific composite type to be known in some cases where it was not before, at the cost of making a separate function cache entry for each named composite type that's passed to the function during a session. The particular symptom discussed in bug #17610 could be solved in other more-efficient ways, but only at the cost of considerable development work, and there are other cases where we'd still fail without this. Per bug #17610 from Martin Jurča. Back-patch to v11 where we first allowed plpgsql functions to be declared as taking type RECORD. Discussion: https://postgr.es/m/17610-fb1eef75bf6c2364@postgresql.org
* Clean up minor inconsistencies in pg_attribute_printf() usage.Tom Lane2022-09-16
| | | | | | | | | | | | | | | | | | | | | For some reason we'd never decorated pg_v*printf() with pg_attribute_printf() annotations. There is a convention for how to label va_list-using printf functions (write zero for the second argument), and we use that liberally elsewhere in the code, but these core functions lacked it. It's not clear how much useful checking the compiler can do for calls of these, but we might as well add the annotations. Also, sync win32security.c's log_error() with our normal convention that pg_attribute_printf must be attached to a function's declaration not definition. Apparently this file is only compiled with compilers that aren't picky about that, but still it'd be better to be consistent. No back-patch since there's little reason to think we would catch anything. Discussion: https://postgr.es/m/3492412.1663283395@sss.pgh.pa.us
* Message wording improvementsPeter Eisentraut2022-09-16
|
* Adjust assorted hint messages that list all valid options.Peter Eisentraut2022-09-16
| | | | | | | | | | Instead of listing all valid options, we now try to provide one that looks similar. Since this may be useful elsewhere, this change introduces a new set of functions that can be reused for similar purposes. Author: Nathan Bossart <nathandbossart@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/b1f9f399-3a1a-b554-283f-4ae7f34608e2@enterprisedb.com
* Fix createdb tests for C localePeter Eisentraut2022-09-16
| | | | | | | | | If the createdb tests run under the C locale, the database cluster will be initialized with encoding SQL_ASCII. With the checks added in c7db01e325a530ec38ec7ba57cd3ed32e123e33c, this will cause several ICU-related tests to fail because SQL_ASCII is not supported by ICU. To work around that, use initdb option -E UTF8 for those tests to get past that check.
* Don't allow creation of database with ICU locale with unsupported encodingPeter Eisentraut2022-09-16
| | | | | | | | | | | | | Check in CREATE DATABASE and initdb that the selected encoding is supported by ICU. Before, they would pass but users would later get an error from the server when they tried to use the database. Also document that initdb sets the encoding to UTF8 by default if the ICU locale provider is chosen. Author: Marina Polyakova <m.polyakova@postgrespro.ru> Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com> Discussion: https://www.postgresql.org/message-id/6dd6db0984d86a51b7255ba79f111971@postgrespro.ru
* Detect format-string mistakes in the libpq_pipeline test module.Tom Lane2022-09-15
| | | | | | | | | | | | | | I happened to notice that libpq_pipeline's private implementation of pg_fatal lacked any pg_attribute_printf decoration. Indeed, adding that turned up a mistake! We'd likely never have noticed because the error exits in this code are unlikely to get hit, but still, it's a bug. We're so used to having the compiler check this stuff for us that a printf-like function without pg_attribute_printf is a land mine. I wonder if there is a way to detect such omissions. Back-patch to v14 where this code came in.
* Revert ill-considered change in pg_resetwal output.Tom Lane2022-09-15
| | | | | | | | | | | | | | | | | | Commit 31dcfae83 changed one pg_resetwal output string, and a corresponding test in pg_upgrade, without sufficient thought for the consequences. We can't change that output without creating hazards for cross-version upgrades, since pg_upgrade needs to be able to read the output of several different versions of pg_resetwal. There may well be external tools with the same requirement. For the moment, just revert those two changes. What we really ought to do here is have a separate, stable, easily machine-readable output format for pg_resetwal and pg_controldata, as proposed years ago by Alvaro. Once that's in place and tools no longer need to depend on the exact spelling of the human-readable output, we can put back this change. Discussion: https://postgr.es/m/fbea8c6f-415a-bad9-c3de-969c40d08a84@dunslane.net
* Reset InstallXLogFileSegmentActive after walreceiver self-initiated exit.Noah Misch2022-09-15
| | | | | | | | | | | | | After commit cc2c7d65fc27e877c9f407587b0b92d46cd6dd16 added this flag, failure to reset it caused assertion failures. In non-assert builds, it made the system fail to achieve the objectives listed in that commit; chiefly, we might emit a spurious log message. Back-patch to v15, where that commit first appeared. Bharath Rupireddy and Kyotaro Horiguchi. Reviewed by Dilip Kumar, Nathan Bossart and Michael Paquier. Reported by Dilip Kumar. Discussion: https://postgr.es/m/CAFiTN-sE3ry=ycMPVtC+Djw4Fd7gbUGVv_qqw6qfzp=JLvqT3g@mail.gmail.com
* Fix grammar in error messageJohn Naylor2022-09-15
| | | | | | | | | | While at it, make ellipses formatting consistent when describing SQL statements. Ekaterina Kiryanova and Alexander Lakhin Reviewed by myself and Álvaro Herrera Discussion: https://www.postgresql.org/message-id/eed5cec0-a542-53da-6a5e-7789c6ed9817%40postgrespro.ru Backpatch only the grammar fix to v15
* Blind attempt to fix LLVM dependency in the backendJohn Naylor2022-09-15
| | | | | | | | | | | | Commit ecaf7c5df5 removed gram.h from the backend's generated-headers target. In LLVM builds, this leads to loss of dependency information when generating .bc files. To fix, add a rule that mirrors ad-hoc .o dependencies for .bc files as well. Per cfbot (no buildfarm failures reported) Analysis by Tom Lane and Andres Freund Proposed fix by Andres Freund Discussion: https://www.postgresql.org/message-id/20220914210427.y26tkagmxo5wwbvp%40awork3.anarazel.de
* Use the terminology "WAL file" not "log file" more consistently.Tom Lane2022-09-14
| | | | | | | | | | | Referring to the WAL as just "log" invites confusion with the postmaster log, so avoid doing that in docs and error messages. Also shorten "WAL segment file" to just "WAL file" in various places. Bharath Rupireddy, reviewed by Nathan Bossart and Kyotaro Horiguchi Discussion: https://postgr.es/m/CALj2ACUeXa8tDPaiTLexBDMZ7hgvaN+RTb957-cn5qwv9zf-MQ@mail.gmail.com
* Fix outdated convert_saop_to_hashed_saop commentDavid Rowley2022-09-15
| | | | | | | | | | | In 29f45e299, we added support for optimizing the execution of NOT IN(values) by using a hash table instead of a linear search over the array. That commit neglected to update the header comment for convert_saop_to_hashed_saop() to mention this fact. Here we fix that. Author: James Coleman Discussion: https://postgr.es/m/CAAaqYe99NUpAPcxgchGstgM23fmiGjqQPot8627YgkBgNt=BfA@mail.gmail.com Backpatch-through: 15, where 29f45e299 was added.
* Small wording improvementsPeter Eisentraut2022-09-14
|
* Doc: add some doco about using the libpq_pipeline test module.Tom Lane2022-09-14
| | | | | | | | The README file here was barely a stub. Try to make it useful. Jelte Fennema, with some further work by me Discussion: https://postgr.es/m/AM5PR83MB0178D3B31CA1B6EC4A8ECC42F7529@AM5PR83MB0178.EURPRD83.prod.outlook.com
* Use SIGNAL_ARGS consistently to declare signal handlers.Tom Lane2022-09-14
| | | | | | | | | | | | Various bits of code were declaring signal handlers manually, using "int signum" or variants of that. We evidently have no platforms where that's actually wrong, but let's use our SIGNAL_ARGS macro everywhere anyway. If nothing else, it's good for finding signal handlers easily. No need for back-patch, since this is just cosmetic AFAICS. Discussion: https://postgr.es/m/2684964.1663167995@sss.pgh.pa.us
* Handle SIGTERM in pg_receivewal and pg_recvlogicalDaniel Gustafsson2022-09-14
| | | | | | | | | | | | | | | | | In pg_receivewal, compressed output is only flushed on clean exits. The reason to support SIGTERM as well as SIGINT (which is currently handled) is that pg_receivewal might well be running as a daemon, and systemd's default KillSignal is SIGTERM. Since pg_recvlogical is also supposed to run as a daemon, teach it about SIGTERM as well and update the documentation to match. While in there, change pg_receivewal's time_to_stop to be sig_atomic_t like it is in pg_recvlogical. Author: Christoph Berg <myon@debian.org> Reviewed-by: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> Reviewed-by: Michael Paquier <michael@paquier.xyz> Discussion: https://postgr.es/m/Yvo/5No5S0c4EFMj@msg.df7cb.de
* Add subxid-overflow "isolation" testAlvaro Herrera2022-09-14
| | | | | | | | | This test covers a few lines of subxid-overflow-handling code in various part of the backend, which are otherwise uncovered. Author: Simon Riggs <simon.riggs@enterprisedb.com> Reviewed-by: Dilip Kumar <dilipbalaut@gmail.com> Discussion: https://postgr.es/m/CANbhV-H8ov5+nCMBYQFKhO+UZJjrFgY_ORiMWr3RhS4+x44PzA@mail.gmail.com
* Remove duplicate initializationAlvaro Herrera2022-09-14
| | | | | | | | | | | | This appears to be a merge mistake in 96ef3237bf74. We could put it back the way it was before JSON_TABLE and it'd be two lines shorter, but it's likely that JSON_TABLE will be back and will prefer things this way. It makes no other difference in practice. Backpatch to 15. Reported by Ranier Vilela Discussion: https://postgr.es/m/CAEudQAr4nOcNQskC4oBEZN4S+4heJ=1ch_ZKOxU+_Ef-FQSf-g@mail.gmail.com
* Fix failure to build gramparse.h standalone in vpath buildsJohn Naylor2022-09-14
| | | | | | Add include directory in a similar fashion as 829906fb6c. Per buildfarm animal crake
* Fix incorrect value for "strategy" with deflateParams() in walmethods.cMichael Paquier2022-09-14
| | | | | | | | | | | | | | The zlib documentation mentions the values supported for the compression strategy, but this code has been using a hardcoded value of 0 rather than Z_DEFAULT_STRATEGY. This commit adjusts the code to use Z_DEFAULT_STRATEGY. Backpatch down to where this code has been added to ease the backport of any future patch touching this area. Reported-by: Tom Lane Discussion: https://postgr.es/m/1400032.1662217889@sss.pgh.pa.us Backpatch-through: 10
* Fix typo in pgbench.c.Amit Kapila2022-09-14
| | | | | Author: Kyotaro Horiguchi Discussion: https://postgr.es/m/20220914.114608.1462991533784489178.horikyota.ntt@gmail.com
* Bump minimum Perl version to 5.14John Naylor2022-09-14
| | | | | | | | | | | | | | | | | | | | The oldest vendor-shipped Perl in the buildfarm is 5.14.2, which is the last version that Debian Wheezy shipped. That OS is EOL, but we keep it running because there is no other convenient way to test certain non-mainstream 32-bit platforms. There is no bugfix in the 5.14.2 release that is required, and yet it's also not the latest minor release -- that would be 5.14.4. To clarify the situation, we have thus arranged the buildfarm to test 5.14.0. That allows configure scripts and documentation to state 5.14 without fine print. The MSVC build didn't check the version, since our previous minimum 5.8.3 was considered too old to check for on Windows. We will need a check for Windows sometime during the v16 cycle, but that could be rendered moot by the impending Meson conversion, so it seems safe to just document the requirement for now. Reviewed by Tom Lane Discussion: https://www.postgresql.org/message-id/20220902181553.ev4pgzhubhdkguuv@awork3.anarazel.de
* Move gramparse.h to src/backend/parserJohn Naylor2022-09-14
| | | | | | | | | | | | | This header is semi-private, being used only in files related to raw parsing, so move to the backend directory where those files live. This allows removal of Makefile rules that symlink gram.h to src/include/parser, since gramparse.h can now include gram.h from within the same directory. This has the side-effect of no longer installing gram.h and gramparse.h, but there doesn't seem to be a good reason to continue doing so. Per suggestion from Andres Freund and Peter Eisentraut Discussion: https://www.postgresql.org/message-id/20220904181759.px6uosll6zbxcum5%40awork3.anarazel.de
* Simplify handling of compression level with compression specificationsMichael Paquier2022-09-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PG_COMPRESSION_OPTION_LEVEL is removed from the compression specification logic, and instead the compression level is always assigned with each library's default if nothing is directly given. This centralizes the checks on the compression methods supported by a given build, and always assigns a default compression level when parsing a compression specification. This results in complaining at an earlier stage than previously if a build supports a compression method or not, aka when parsing a specification in the backend or the frontend, and not when processing it. zstd, lz4 and zlib are able to handle in their respective routines setting up the compression level the case of a default value, hence the backend or frontend code (pg_receivewal or pg_basebackup) has now no need to know what the default compression level should be if nothing is specified: the logic is now done so as the specification parsing assigns it. It can also be enforced by passing down a "level" set to the default value, that the backend will accept (the replication protocol is for example able to handle a command like BASE_BACKUP (COMPRESSION_DETAIL 'gzip:level=-1')). This code simplification fixes an issue with pg_basebackup --gzip introduced by ffd5365, where the tarball of the streamed WAL segments would be created as of pg_wal.tar.gz with uncompressed contents, while the intention is to compress the segments with gzip at a default level. The origin of the confusion comes from the handling of the default compression level of gzip (-1 or Z_DEFAULT_COMPRESSION) and the value of 0 was getting assigned, which is what walmethods.c would consider as equivalent to no compression when streaming WAL segments with its tar methods. Assigning always the compression level removes the confusion of some code paths considering a value of 0 set in a specification as either no compression or a default compression level. Note that 010_pg_basebackup.pl has to be adjusted to skip a few tests where the shape of the compression detail string for client and server-side compression was checked using gzip. This is a result of the code simplification, as gzip specifications cannot be used if a build does not support it. Reported-by: Tom Lane Reviewed-by: Tom Lane Discussion: https://postgr.es/m/1400032.1662217889@sss.pgh.pa.us Backpatch-through: 15
* Split up guc.c for better build speed and ease of maintenance.Tom Lane2022-09-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | guc.c has grown to be one of our largest .c files, making it a bottleneck for compilation. It's also acquired a bunch of knowledge that'd be better kept elsewhere, because of our not very good habit of putting variable-specific check hooks here. Hence, split it up along these lines: * guc.c itself retains just the core GUC housekeeping mechanisms. * New file guc_funcs.c contains the SET/SHOW interfaces and some SQL-accessible functions for GUC manipulation. * New file guc_tables.c contains the data arrays that define the built-in GUC variables, along with some already-exported constant tables. * GUC check/assign/show hook functions are moved to the variable's home module, whenever that's clearly identifiable. A few hard- to-classify hooks ended up in commands/variable.c, which was already a home for miscellaneous GUC hook functions. To avoid cluttering a lot more header files with #include "guc.h", I also invented a new header file utils/guc_hooks.h and put all the GUC hook functions' declarations there, regardless of their originating module. That allowed removal of #include "guc.h" from some existing headers. The fallout from that (hopefully all caught here) demonstrates clearly why such inclusions are best minimized: there are a lot of files that, for example, were getting array.h at two or more levels of remove, despite not having any connection at all to GUCs in themselves. There is some very minor code beautification here, such as renaming a couple of inconsistently-named hook functions and improving some comments. But mostly this just moves code from point A to point B and deals with the ensuing needs for #include adjustments and exporting a few functions that previously weren't exported. Patch by me, per a suggestion from Andres Freund; thanks also to Michael Paquier for the idea to invent guc_funcs.c. Discussion: https://postgr.es/m/587607.1662836699@sss.pgh.pa.us
* Don't reflect unescaped cert data to the logsPeter Eisentraut2022-09-13
| | | | | | | | | | | | | | | | | | | | | | Commit 3a0e385048 introduced a new path for unauthenticated bytes from the client certificate to be printed unescaped to the logs. There are a handful of these already, but it doesn't make sense to keep making the problem worse. \x-escape any unprintable bytes. The test case introduces a revoked UTF-8 certificate. This requires the addition of the `-utf8` flag to `openssl req`. Since the existing certificates all use an ASCII subset, this won't modify the existing certificates' subjects if/when they get regenerated; this was verified experimentally with $ make sslfiles-clean $ make sslfiles Unfortunately the test can't be run in the CI yet due to a test timing issue; see 55828a6b60. Author: Jacob Champion <jchampion@timescale.com> Discussion: https://www.postgresql.org/message-id/CAAWbhmgsvHrH9wLU2kYc3pOi1KSenHSLAHBbCVmmddW6-mc_=w@mail.gmail.com
* pg_clean_ascii(): escape bytes rather than lose themPeter Eisentraut2022-09-13
| | | | | | | | | Rather than replace each unprintable byte with a '?' character, replace it with a hex escape instead. The API now allocates a copy rather than modifying the input in place. Author: Jacob Champion <jchampion@timescale.com> Discussion: https://www.postgresql.org/message-id/CAAWbhmgsvHrH9wLU2kYc3pOi1KSenHSLAHBbCVmmddW6-mc_=w@mail.gmail.com
* Make locale option behavior more consistentPeter Eisentraut2022-09-13
| | | | | | | | | | | | | | | | | | | Locale options can be specified for initdb, createdb, and CREATE DATABASE. In initdb, it has always been possible to specify --locale and then some --lc-* option to override a category. CREATE DATABASE and createdb didn't allow that, requiring either the all-categories option or only per-category options. In f2553d43060edb210b36c63187d52a632448e1d2, this was changed in CREATE DATABASE (perhaps by accident?) to be more like the initdb behavior, but createdb still had the old behavior. Now we change createdb to match the behavior of CREATE DATABASE and initdb, and also update the documentation of CREATE DATABASE to match the new behavior, which was not done in the above commit. Author: Marina Polyakova <m.polyakova@postgrespro.ru> Reviewed-by: Justin Pryzby <pryzby@telsasoft.com> Discussion: https://www.postgresql.org/message-id/7c99c132dc9c0ac630e0127f032ac480@postgrespro.ru
generated by cgit v1.2.3 (git 2.25.1) at 2025-05-28 20:01:47 +0000