aboutsummaryrefslogtreecommitdiff
path: root/src/backend
Commit message (Collapse)AuthorAge
...
* Fix InitializeRelfilenumberMap for 05d4cbf9b6ba708858984b01ca0fc56d59d4ec7cRobert Haas2022-09-28
| | | | | | | | | | | Since relfilenodes are now 56-bits, we use bigint as the SQL type to represent them, which means F_INT8EQ must be used here rather than F_OIDEQ. On 64-bit machines this doesn't matter, but 32-bit machines are unhappy. Dilip Kumar Discussion: http://postgr.es/m/CAFiTN-t71ciSckMzixAhrF9py7oRO6xszKi4mTRwjuucXr5tpw@mail.gmail.com
* Fix alignment problems with SharedInvalSmgrMsg.Robert Haas2022-09-28
| | | | | | | | | | | | SharedInvalSmgrMsg can't require 8-byte alignment, because then SharedInvalidationMessage will require 8-byte alignment, which will then cause ParseCommitRecord to fail on machines that are picky about alignment, because it assumes that everything that gets packed into a commit record requires only 4-byte alignment. Another problem with 05d4cbf9b6ba708858984b01ca0fc56d59d4ec7c. Discussion: http://postgr.es/m/3825454.1664310917@sss.pgh.pa.us
* Remove publicationcmds.c's expr_allowed_in_node as a functionAlvaro Herrera2022-09-28
| | | | | | | | Its API is quite strange, and since there's only one caller, there's no reason for it to be a separate function in the first place. Inline it instead. Discussion: https://postgr.es/m/20220927124249.4zdzzlz6had7k3x2@alvherre.pgsql
* Fix some comments of do_pg_backup_start() and do_pg_backup_stop()Michael Paquier2022-09-28
| | | | | | | | | | Both functions referred to an incorrect variable name, so make the whole more consistent. Oversight in 7d70809. Author: Kyotaro Horiguchi, Bharath Rupireddy Discussion: https://postgr.es/m/20220927.172427.467118514018439476.horikyota.ntt@gmail.com
* Fix typos in commit 05d4cbf9b6ba708858984b01ca0fc56d59d4ec7c.Robert Haas2022-09-27
| | | | | | Reported by Justin Pryzby. Discussion: http://postgr.es/m/20220927185121.GE6256@telsasoft.com
* Convert *GetDatum() and DatumGet*() macros to inline functionsPeter Eisentraut2022-09-27
| | | | | | | | | | | | | | The previous macro implementations just cast the argument to a target type but did not check whether the input type was appropriate. The function implementation can do better type checking of the input type. For the *GetDatumFast() macros, converting to an inline function doesn't work in the !USE_FLOAT8_BYVAL case, but we can use AssertVariableIsOfTypeMacro() to get a similar level of type checking. Reviewed-by: Aleksander Alekseev <aleksander@timescale.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://www.postgresql.org/message-id/flat/8528fb7e-0aa2-6b54-85fb-0c0886dbd6ed%40enterprisedb.com
* Increase width of RelFileNumbers from 32 bits to 56 bits.Robert Haas2022-09-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | RelFileNumbers are now assigned using a separate counter, instead of being assigned from the OID counter. This counter never wraps around: if all 2^56 possible RelFileNumbers are used, an internal error occurs. As the cluster is limited to 2^64 total bytes of WAL, this limitation should not cause a problem in practice. If the counter were 64 bits wide rather than 56 bits wide, we would need to increase the width of the BufferTag, which might adversely impact buffer lookup performance. Also, this lets us use bigint for pg_class.relfilenode and other places where these values are exposed at the SQL level without worrying about overflow. This should remove the need to keep "tombstone" files around until the next checkpoint when relations are removed. We do that to keep RelFileNumbers from being recycled, but now that won't happen anyway. However, this patch doesn't actually change anything in this area; it just makes it possible for a future patch to do so. Dilip Kumar, based on an idea from Andres Freund, who also reviewed some earlier versions of the patch. Further review and some wordsmithing by me. Also reviewed at various points by Ashutosh Sharma, Vignesh C, Amul Sul, Álvaro Herrera, and Tom Lane. Discussion: http://postgr.es/m/CA+Tgmobp7+7kmi4gkq7Y+4AM9fTvL+O1oQ4-5gFTT+6Ng-dQ=g@mail.gmail.com
* Introduce GUC_NO_RESET flag.Tom Lane2022-09-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, the transaction-property GUCs such as transaction_isolation could be reset after starting a transaction, because we marked them as GUC_NO_RESET_ALL but still allowed a targeted RESET. That leads to assertion failures or worse, because those properties aren't supposed to change after we've acquired a transaction snapshot. There are some NO_RESET_ALL variables for which RESET is okay, so we can't just redefine the semantics of that flag. Instead introduce a separate GUC_NO_RESET flag. Mark "seed", as well as the transaction property GUCs, as GUC_NO_RESET. We have to disallow GUC_ACTION_SAVE as well as straight RESET, because otherwise a function having a "SET transaction_isolation" clause can still break things: the end-of-function restore action is equivalent to a RESET. No back-patch, as it's conceivable that someone is doing something this patch will forbid (like resetting one of these GUCs at transaction start, or "CREATE FUNCTION ... SET transaction_read_only = 1") and not running into problems with it today. Given how long we've had this issue and not noticed, the side effects in non-assert builds can't be too serious. Per bug #17385 from Andrew Bille. Masahiko Sawada Discussion: https://postgr.es/m/17385-9ee529fb091f0ce5@postgresql.org
* Improve some publication-related error messagesAlvaro Herrera2022-09-27
| | | | | | | | | | | While at it, remove an unused queryString parameter from CheckPubRelationColumnList() and make other minor stylistic changes. Backpatch to 15. Reported by Kyotaro Horiguchi <horikyota.ntt@gmail.com> Co-authored-by: Hou zj <houzj.fnst@fujitsu.com> Discussion: https://postgr.es/m/20220926.160426.454497059203258582.horikyota.ntt@gmail.com
* Fix pg_stat_statements for MERGEAlvaro Herrera2022-09-27
| | | | | | | | | | | | We weren't jumbling the merge action list, so wildly different commands would be considered to use the same query ID. Add that, mention it in the docs, and some test lines. Backpatch to 15. Author: Tatsu <bt22nakamorit@oss.nttdata.com> Reviewed-by: Julien Rouhaud <rjuju123@gmail.com> Discussion: https://postgr.es/m/d87e391694db75a038abc3b2597828e8@oss.nttdata.com
* Mark ParallelMessagePending as sig_atomic_tMichael Paquier2022-09-27
| | | | | | | | | ParallelMessagePending was previously marked as a boolean which should be fine on modern platforms, but the C standard recommends the use of sig_atomic_t for variables manipulated in signal handlers. Author: Hayato Kuroda Discussion: https://postgr.es/m/TYAPR01MB58667C15A95A234720F4F876F5529@TYAPR01MB5866.jpnprd01.prod.outlook.com
* Remove dependency to StringInfo in xlogbackup.{c.h}Michael Paquier2022-09-27
| | | | | | | | | | This was used as the returned result type of the generated contents for the backup_label and backup history files. This is replaced by a simple string, reducing the cleanup burden of all the callers of build_backup_content(). Reviewed-by: Bharath Rupireddy Discussion: https://postgr.es/m/YzERvNPaZivHEKZJ@paquier.xyz
* Enable WRITE_READ_PARSE_PLAN_TREES of rewritten utility statementsTom Lane2022-09-26
| | | | | | | | This was previously disabled because we lacked outfuncs/readfuncs support for most utility statement types. Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://www.postgresql.org/message-id/flat/4159834.1657405226@sss.pgh.pa.us
* Implement WRITE_READ_PARSE_PLAN_TREES for raw parse treesTom Lane2022-09-26
| | | | | Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://www.postgresql.org/message-id/flat/4159834.1657405226@sss.pgh.pa.us
* Don't lose precision for float fields of Nodes.Peter Eisentraut2022-09-26
| | | | | | | | | | 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
* Fix write/read of empty string fields in Nodes.Peter Eisentraut2022-09-26
| | | | | | | | | | | | | | | | | | 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
* Remove unused xid parameter.Amit Kapila2022-09-26
| | | | | | | | | | 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
* Refactor creation of backup_label and backup history filesMichael Paquier2022-09-26
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix tupdesc lifespan bug with AfterTriggersTableData.storeslot.Tom Lane2022-09-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Message style improvementsPeter Eisentraut2022-09-24
|
* Add read support for some missing raw parse nodesPeter Eisentraut2022-09-24
| | | | | | | | | | | | | | | | | 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
* Fix reading of BitString nodesPeter Eisentraut2022-09-24
| | | | | | | | | | | | | 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
* Fix reading of most-negative integer value nodesPeter Eisentraut2022-09-24
| | | | | | | | | | | | | | | | | | | | | | 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
* Remove uses of register due to incompatibility with C++17 and upAndres Freund2022-09-24
| | | | | | | | 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
* pgstat: Fix transactional stats dropping for indexesAndres Freund2022-09-23
| | | | | | | | | | | | | | | | | | | | 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 8b1dccd37c71, which introduced the bug
* Allow publications with schema and table of the same schema.Amit Kapila2022-09-23
| | | | | | | | | | | | | | | | | | | | | 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
* Harmonize more lexer function parameter names.Peter Geoghegan2022-09-22
| | | | | | | | | 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
* Fix race condition where heap_delete() fails to pin VM page.Jeff Davis2022-09-22
| | | | | | | | | | 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
* Remove ALL keyword from TABLES IN SCHEMA for publicationAlvaro Herrera2022-09-22
| | | | | | | | | | | | | | | | | | 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
* Fix thinko in comment.Etsuro Fujita2022-09-22
| | | | | | | 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
* meson: Add initial version of meson based build systemAndres Freund2022-09-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Clear ps display of startup process at the end of recoveryMichael Paquier2022-09-22
| | | | | | | | | | | | | | | | | 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
* Used optimized linear search in more code pathsMichael Paquier2022-09-22
| | | | | | | | | | | | | | | | | 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
* Improve ICU option handling in CREATE DATABASEPeter Eisentraut2022-09-21
| | | | | | | | | | 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
* Tighten pg_get_object_address argument checkingPeter Eisentraut2022-09-21
| | | | | | | | | | | | 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
* Improve some GUC description stringsAlvaro Herrera2022-09-21
| | | | | | | | | 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
* Pass Size as a 2nd argument for snprintf() in tablesync.c.Amit Kapila2022-09-21
| | | | | | | | | | | | | | | 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
* Improve some error messages.Amit Kapila2022-09-21
| | | | | | | | 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
* Revise tree-walk APIs to improve spec compliance & silence warnings.Tom Lane2022-09-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix recent cpluspluscheck issue in selfuncs.h.Peter Geoghegan2022-09-20
| | | | | | | | | | | Fix selfuncs.h cpluspluscheck complaint, without reintroducing a parameter name inconsistency (restore the original declaration names, and then make corresponding function definitions consistent with that). Oversight in commit a601366a. Author: Peter Geoghegan <pg@bowt.ie> Reported-By: Andres Freund <andres@anarazel.de>
* Harmonize more parameter names in bulk.Peter Geoghegan2022-09-20
| | | | | | | | | | | | | | | | Make sure that function declarations use names that exactly match the corresponding names from function definitions in optimizer, parser, utility, libpq, and "commands" code, as well as in remaining library code. Do the same for all code related to frontend programs (with the exception of pg_dump/pg_dumpall related code). Like other recent commits that cleaned up function parameter names, this commit was written with help from clang-tidy. Later commits will handle ecpg and pg_dump/pg_dumpall. 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
* Suppress variable-set-but-not-used warnings from clang 15.Tom Lane2022-09-20
| | | | | | | | | | | | | | | | | | | | | | | | clang 15+ will issue a set-but-not-used warning when the only use of a variable is in autoincrements (e.g., "foo++;"). That's perfectly sensible, but it detects a few more cases that we'd not noticed before. Silence the warnings with our usual methods, such as PG_USED_FOR_ASSERTS_ONLY, or in one case by actually removing a useless variable. One thing that we can't nicely get rid of is that with %pure-parser, Bison emits "yynerrs" as a local variable that falls foul of this warning. To silence those, I inserted "(void) yynerrs;" in the top-level productions of affected grammars. Per recently-established project policy, this is a candidate for back-patching into out-of-support branches: it suppresses annoying compiler warnings but changes no behavior. Hence, back-patch to 9.5, which is as far as these patches go without issues. (A preliminary check shows that the prior branches need some other set-but-not-used cleanups too, so I'll leave them for another day.) Discussion: https://postgr.es/m/514615.1663615243@sss.pgh.pa.us
* Fix incorrect variable types for origin IDs in decode.cMichael Paquier2022-09-20
| | | | | | | | These variables used XLogRecPtr instead of RepOriginId. Author: Masahiko Sawada Discussion: https://postgr.es/m/CAD21AoBm-vNyBSXGp4bmJGvhr=S-EGc5q1dtV70cFTcJvLhC=Q@mail.gmail.com Backpatch-through: 14
* Harmonize parameter names in storage and AM code.Peter Geoghegan2022-09-19
| | | | | | | | | | | | | | | Make sure that function declarations use names that exactly match the corresponding names from function definitions in storage, catalog, access method, executor, and logical replication code, as well as in miscellaneous utility/library code. Like other recent commits that cleaned up function parameter names, this commit was written with help from clang-tidy. Later commits will do the same for other parts of the codebase. 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
* Harmonize heapam and tableam parameter names.Peter Geoghegan2022-09-19
| | | | | | | | | | | | | | | | Make sure that function declarations use names that exactly match the corresponding names from function definitions. Having parameter names that are reliably consistent in this way will make it easier to reason about groups of related C functions from the same translation unit as a module. It will also make certain refactoring tasks easier. Like other recent commits that cleaned up function parameter names, this commit was written with help from clang-tidy. Later commits will do the same for other parts of the codebase. 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
* Consistently use named parameters in regex code consistently.Peter Geoghegan2022-09-19
| | | | | | | | | | Adjust a handful of remaining function prototypes that were overlooked by recent commit bc2187ed. This oversight wasn't caught by clang-tidy because the functions in question are only built in custom REG_DEBUG builds. Author: Peter Geoghegan <pg@bowt.ie> Reported-By: Tom Lane <tgl@sss.pgh.pa.us>
* Consistently use named parameters in regex code.Peter Geoghegan2022-09-19
| | | | | | | | | | | | Make regex code consistently use named parameters in function declarations. Also make sure that parameter names from each function's declaration match corresponding definition parameter names. This makes Henry Spencer's regex code follow Postgres coding standards. 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
* 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