aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAge
* Follow-up fixes for "Make all Perl warnings fatal"Peter Eisentraut2023-12-29
| | | | | Mostly, we need to check whether $ENV{PG_TEST_EXTRA} is set before doing regular expression matches against it.
* Fix collate.windows.win1252 test.Jeff Davis2023-12-29
| | | | | | | | | Do not rely on the OS recognizing a particular locale; find the right locale by querying the "en_US" collation. Author: Alexander Lakhin Reported-by: Alexander Lakhin Discussion: https://postgr.es/m/ae73f6f5-8221-c112-4640-5cda812a69de@gmail.com
* Make all Perl warnings fatalPeter Eisentraut2023-12-29
| | | | | | | | | | | | | | | | | | | | | | | | There are a lot of Perl scripts in the tree, mostly code generation and TAP tests. Occasionally, these scripts produce warnings. These are probably always mistakes on the developer side (true positives). Typical examples are warnings from genbki.pl or related when you make a mess in the catalog files during development, or warnings from tests when they massage a config file that looks different on different hosts, or mistakes during merges (e.g., duplicate subroutine definitions), or just mistakes that weren't noticed because there is a lot of output in a verbose build. This changes all warnings into fatal errors, by replacing use warnings; by use warnings FATAL => 'all'; in all Perl files. Discussion: https://www.postgresql.org/message-id/flat/06f899fd-1826-05ab-42d6-adeb1fd5e200%40eisentraut.org
* In pg_dump, don't dump a stats object unless dumping underlying table.Tom Lane2023-12-29
| | | | | | | | | | | | | | | | If the underlying table isn't being dumped, it's useless to dump an extended statistics object; it'll just cause errors at restore. We have always applied similar policies to, say, indexes. (When and if we get cross-table stats objects, it might be profitable to think a little harder about what to do with them. But for now there seems no point in considering a stats object as anything but an appendage of its table.) Rian McGuire and Tom Lane, per report from Rian McGuire. Back-patch to supported branches. Discussion: https://postgr.es/m/7075d3aa-3f05-44a5-b68f-47dc6a8a0550@buildkite.com
* Fix variable name and commentPeter Eisentraut2023-12-28
| | | | | | Should match the name of the related GUC variable. Discussion: https://www.postgresql.org/message-id/da4a680a-5d8a-4663-a5c8-a3ccbf23394a@eisentraut.org
* doc: Mention AttributeRelationId in FDW validator function descriptionMichael Paquier2023-12-28
| | | | | | | | | | | The documentation has been missing one value in the list of catalog OIDs that can be given to the validator function of a FDW, as of AttributeRelationId, when changing the attribute options of a foreign table. Author: Ian Lawrence Barwick Discussion: https://postgr.es/m/CAB8KJ=i16t2yJU_Pq2Z+hnNGWFhagp_bJmzxHZu3ZkOjZm-+rQ@mail.gmail.com Backpatch-through: 12
* Improve the implementation of information_schema._pg_expandarray().Tom Lane2023-12-27
| | | | | | | | | | | | | | | | | | | | | This function was originally coded with a handmade expansion of the array subscripts. We can do it a little faster and far more legibly today, by using unnest() WITH ORDINALITY. While at it, let's apply the rowcount estimation support that exists for the underlying unnest() function: reduce the default ROWS estimate to 100 and attach array_unnest_support. I'm not sure that array_unnest_support can do anything useful today with the call sites that exist in information_schema, but it can't hurt, and the existing default rowcount of 1000 is surely much too high for any of these cases. The psql.sql regression script is using _pg_expandarray() as a test case for \sf+. While we could keep doing so, the new one-line function body makes a poor test case for \sf+ row-numbering, so switch it to print another information_schema function. Discussion: https://postgr.es/m/1424303.1703355485@sss.pgh.pa.us
* Doc: specify aclitem syntax more clearly.Tom Lane2023-12-27
| | | | | | | | | | The previous wording here relied solely on an example to explain aclitem output format. Add an actual syntax synopsis and explanation of the elements to make it clearer. David Johnston and Tom Lane, per gripe from Eugen Konkov. Discussion: https://postgr.es/m/170326116972.1876499.18357820037829248593@wrigleys.postgresql.org
* Fix another incorrect data type choice from commit dc2123400.Tom Lane2023-12-27
| | | | | | | | | | | | | add_file_to_manifest declared its mtime argument as pg_time_t, apparently on the principle that copy-and-paste from the backend is fine. However, the callers are passing struct stat's st_mtime field which is plain time_t, and add_file_to_manifest itself is passing the value to gmtime(3) which expects plain time_t, so the whole thing would not work at all on any platform where those types are different. Fortunately we can just switch this variable to time_t. Per warnings from assorted buildfarm members.
* Fix incorrect format placeholdersPeter Eisentraut2023-12-27
|
* Fix a warning in Perl test codePeter Eisentraut2023-12-27
| | | | | | | | | | | | | | The code was passing a scalar argument to node->restart(), but it was expecting a hash, which causes a warning from Perl ("Odd number of elements in hash assignment"). But the node->restart() function doesn't take a mode argument anyway. This was probably copied from an incorrect comment (see commit 750c59d7ec). The default restart mode is already "fast", so the test should still be semantically correct without explicitly specifying the mode. Discussion: https://www.postgresql.org/message-id/e3f4bf1b-63d3-408a-b07e-d35a0fdf1b98@eisentraut.org
* Fix incorrect data type choices in some read and write calls.Tom Lane2023-12-27
| | | | | | | | | | | | | | | | | | | | | | | | Recently-introduced code in reconstruct.c was using "unsigned" to store the result of read(), pg_pread(), or write(). This is completely bogus: it breaks subsequent tests for the result being negative, as we're being reminded of by a chorus of buildfarm warnings. Switch to "int" as was doubtless intended. (There are several other uses of "unsigned" in this file that also look poorly chosen to me, but for now I'm just trying to clean up the buildfarm.) A larger problem is that "int" is not necessarily wide enough to hold the result: per POSIX, all these functions return ssize_t. In places where the requested read or write length clearly fits in int, that's academic. It may be academic anyway as long as we constrain individual data files to 1GB, since even a readv or writev-like operation would then not be responsible for transferring more than 1GB. Nonetheless it seems like trouble waiting to happen, so I made a pass over readv and writev calls and fixed the result variables where that seemed appropriate. We might want to think about changing some of the fd.c functions to return ssize_t too, for future-proofing; but I didn't tackle that here. Discussion: https://postgr.es/m/1672202.1703441340@sss.pgh.pa.us
* Initialize variable to placate compiler.Robert Haas2023-12-27
| | | | | | | | | | | | I don't think there's a real problem here, because if we reach the loop over 'tles' then we will either find at least one TimeLineHistoryEntry such that oldest_segno != 0, in which case unsummarized_lsn will be initialized, or else unsummarized_tli will remain 0 and an error will occur before unsummarized_lsn is used for anything. But some compilers are complainining, as reported on list by Nathan Bossart and off-list by Andrew Dunstan. Discussion: http://postgr.es/m/20231223215147.GA69623@nathanxps13
* Improvements and fixes for e0b1ee17dcAlexander Korotkov2023-12-27
| | | | | | | | | | | | | | | | | | | | | | e0b1ee17dc introduced optimization for matching B-tree scan keys required for the directional scan. However, it incorrectly assumed that all keys required for opposite direction scan are satisfied by _bt_first(). It has been illustrated that with multiple scan keys over the same column, a lesser one (according to the scan direction) could win leaving the other one unsatisfied. Instead of relying on _bt_first() this commit introduces code that memorizes whether there was at least one match on the page. If that's true we know that keys required for opposite-direction scan are satisfied as soon as corresponding values are not NULLs. Also, this commit simplifies the description for the optimization of keys required for the current direction scan. Now the flag used for this is named continuescanPrechecked and means exactly that *continuescan flag is known to be true for the last item on the page. Reported-by: Peter Geoghegan Discussion: https://postgr.es/m/CAH2-Wzn0LeLcb1PdBnK0xisz8NpHkxRrMr3NWJ%2BKOK-WZ%2BQtTQ%40mail.gmail.com Reviewed-by: Pavel Borisov
* Remove BTScanOpaqueData.firstPageAlexander Korotkov2023-12-27
| | | | | | | | | | It's not necessary to keep the firstPage flag as a field of BTScanOpaqueData. This commit makes it an argument of the _bt_readpage() function. We can easily distinguish first-time and repeated calls (within the scan) of this function. Reported-by: Peter Geoghegan Discussion: https://postgr.es/m/CAH2-Wzk4SOsw%2BtHuTFiz8U9Jqj-R77rYPkhWKODCBb1mdHACXA%40mail.gmail.com Reviewed-by: Pavel Borisov
* pg_stat_statements: Add test coverage for pg_stat_statements_reset_1_7Peter Eisentraut2023-12-27
| | | | | | | | Run pg_stat_statements_reset() once while the appropriate extension version is installed. Reviewed-by: Michael Paquier <michael@paquier.xyz> Discussion: https://www.postgresql.org/message-id/flat/40d1e4f2-835f-448f-a541-8ff5db75bf3d@eisentraut.org
* pg_stat_statements: Add test coverage for pg_stat_statements_1_8()Peter Eisentraut2023-12-27
| | | | | | | | This requires reading pg_stat_statements at least once while the 1.8 version of the extension is installed. Reviewed-by: Michael Paquier <michael@paquier.xyz> Discussion: https://www.postgresql.org/message-id/flat/40d1e4f2-835f-448f-a541-8ff5db75bf3d@eisentraut.org
* Fix typo and case in messagesJohn Naylor2023-12-27
| | | | | | | | | Follow up to dc2123400 Kyotaro Horiguchi Discussion: https://postgr.es/m/20231222.154939.1509525390095583358.horikyota.ntt@gmail.com Discussion: https://postgr.es/m/20231225.145124.1745560266993421173.horikyota.ntt@gmail.com
* Make replace_relid() leave argument unmodifiedAlexander Korotkov2023-12-27
| | | | | | | | | | There are a lot of situations when we share the same pointer to a Bitmapset structure across different places. In order to evade undesirable side effects replace_relid() function should always return a copy. Reported-by: Richard Guo Discussion: https://postgr.es/m/CAMbWs4_wJthNtYBL%2BSsebpgF-5L2r5zFFk6xYbS0A78GKOTFHw%40mail.gmail.com Reviewed-by: Richard Guo, Andres Freund, Ashutosh Bapat, Andrei Lepikhov
* REALLOCATE_BITMAPSETS manual compile-time optionAlexander Korotkov2023-12-27
| | | | | | | | This option forces each bitmapset modification to reallocate bitmapset. This is useful for debugging hangling pointers to bitmapset's. Discussion: https://postgr.es/m/CAMbWs4_wJthNtYBL%2BSsebpgF-5L2r5zFFk6xYbS0A78GKOTFHw%40mail.gmail.com Reviewed-by: Richard Guo, Andres Freund, Ashutosh Bapat, Andrei Lepikhov
* Add asserts to bimapset manipulation functionsAlexander Korotkov2023-12-27
| | | | | | | | New asserts validate that arguments are really bitmapsets. This should help to early detect accesses to dangling pointers. Discussion: https://postgr.es/m/CAMbWs4_wJthNtYBL%2BSsebpgF-5L2r5zFFk6xYbS0A78GKOTFHw%40mail.gmail.com Reviewed-by: Richard Guo, Andres Freund, Ashutosh Bapat, Andrei Lepikhov
* Fix failure to verify PGC_[SU_]BACKEND GUCs in pg_file_settings view.Tom Lane2023-12-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | set_config_option() bails out early if it detects that the option to be set is PGC_BACKEND or PGC_SU_BACKEND class and we're reading the config file in a postmaster child; we don't want to apply any new value in such a case. That's fine as far as it goes, but it fails to consider the requirements of the pg_file_settings view: for that, we need to check validity of the value even though we have no intention to apply it. Because we didn't, even very silly values for affected GUCs would be reported as valid by the view. There are only half a dozen such GUCs, which perhaps explains why this got overlooked for so long. Fix by continuing when changeVal is false; this parallels the logic in some other early-exit paths. Also, the check added by commit 924bcf4f1 to prevent GUC changes in parallel workers seems a few bricks shy of a load: it's evidently assuming that ereport(elevel, ...) won't return. Make sure we bail out if it does. The lack of trouble reports suggests that this is only a latent bug, i.e. parallel workers don't actually reach here with elevel < ERROR. (Per the code coverage report, we never reach here at all in the regression suite.) But we clearly don't want to risk proceeding if that does happen. Per report from Rıdvan Korkmaz. These are ancient bugs, so back-patch to all supported branches. Discussion: https://postgr.es/m/2089235.1703617353@sss.pgh.pa.us
* Fix mistaken file name in plpython's meson recipe.Tom Lane2023-12-26
| | | | Brown-paper-bag bug in commit 58c3151bb. Per buildfarm.
* Hide warnings from Python headers when using gcc-compatible compiler.Tom Lane2023-12-26
| | | | | | | | | | | | | | | | | | | | Like commit 388e80132, use "#pragma GCC system_header" to silence warnings appearing within the Python headers, since newer Python versions no longer worry about some restrictions we still use like -Wdeclaration-after-statement. This patch improves on 388e80132 by inventing a separate wrapper header file, allowing the pragma to be tightly scoped to just the Python headers and not other stuff we have laying about in plpython.h. I applied the same technique to plperl for the same reason: the original patch suppressed warnings for a good deal of our own code, not only the Perl headers. Like the previous commit, back-patch to supported branches. Peter Eisentraut and Tom Lane Discussion: https://postgr.es/m/ae523163-6d2a-4b81-a875-832e48dec502@eisentraut.org
* Add meson NLS support for pg_combinebackupPeter Eisentraut2023-12-26
|
* doc: add ISO 8601 extended format example using to_char()Bruce Momjian2023-12-26
| | | | | | | | | | Reported-by: juha.mustonen@iki.fi Discussion: https://postgr.es/m/20170217160154.6101.52806@wrigleys.postgresql.org Co-authored-by: Erik Wienhold Backpatch-through: master
* Add empty placeholder LINGUAS file for pg_combinebackup.Tom Lane2023-12-26
| | | | | | | This will eventually be replaced once some translations exist for pg_combinebackup's messages. In the meantime, we need something here to prevent "make" from complaining in builds with --enable-nls. Per advice added in 88dad06b4.
* Remove unused macroPeter Eisentraut2023-12-26
| | | | Usage was removed in 6c5576075b but the definition was not removed.
* Fix some translatable strings in pg_basebackup and pg_combinebackupMichael Paquier2023-12-26
| | | | | | | | Two translatable strings introduced in dc212340058b were split into two parts, making their translation harder than necessary. Author: Kyotaro Horiguchi Discussion: https://postgr.es/m/20231225.134747.2287499067164862136.horikyota.ntt@gmail.com
* Doc: Add missing pgoutput options.Amit Kapila2023-12-26
| | | | | | | | | We forgot to update the docs while adding new options in pgoutput. Author: Emre Hasegeli Reviewed-by: Peter Smith, Amit Kapila Backpatch-through: 12 Discussion: https://postgr.es/m/CAE2gYzwdwtUbs-tPSV-QBwgTubiyGD2ZGsSnAVsDfAGGLDrGOA%40mail.gmail.com
* Fix erroneous -Werror=missing-braces on old GCC.Tom Lane2023-12-24
| | | | | | | | | | In the same spirit as 5e0c761d0 and some earlier commits, suppress a chorus of buildfarm warnings about braces in these initializers. Richard Guo Discussion: https://postgr.es/m/CAMbWs48GzM-Ff7vr=_CeqaXxFBB9UntqtaW1cjU8hOo62AbOOg@mail.gmail.com
* Fix a comment for remove_self_joins_recurse()Alexander Korotkov2023-12-25
| | | | | | Discussion: https://postgr.es/m/18187-831da249cbd2ff8e%40postgresql.org Author: Richard Guo Reviewed-by: Andrei Lepikhov
* Don't constrain self-join removal due to PHVsAlexander Korotkov2023-12-25
| | | | | | | | | | Self-join removal appears to be safe to apply with placeholder variables as long as we handle PlaceHolderVar in replace_varno_walker() and replace relid in phinfo->ph_lateral. Discussion: https://postgr.es/m/18187-831da249cbd2ff8e%40postgresql.org Author: Richard Guo Reviewed-by: Andrei Lepikhov
* Handle PlaceHolderVar case in replace_varno_walkerAlexander Korotkov2023-12-25
| | | | | | | | | This commit also retires sje_walker. This increases the generalty of replacing varno in the parse tree and simplifies the code. Discussion: https://postgr.es/m/18187-831da249cbd2ff8e%40postgresql.org Author: Richard Guo Reviewed-by: Andrei Lepikhov
* Enhance checkpointer restartpoint statisticsAlexander Korotkov2023-12-25
| | | | | | | | | | | | | | | | | | | | | | | | Bhis commit introduces enhancements to the pg_stat_checkpointer view by adding three new columns: restartpoints_timed, restartpoints_req, and restartpoints_done. These additions aim to improve the visibility and monitoring of restartpoint processes on replicas. Previously, it was challenging to differentiate between successful and failed restartpoint requests. This limitation arises because restartpoints on replicas are dependent on checkpoint records from the primary, and cannot occur more frequently than these checkpoints. The new columns allow for clear distinction and tracking of restartpoint requests, their triggers, and successful completions. This enhancement aids database administrators and developers in better understanding and diagnosing issues related to restartpoint behavior, particularly in scenarios where restartpoint requests may fail. System catalog is changed. Catversion is bumped. Discussion: https://postgr.es/m/99b2ccd1-a77a-962a-0837-191cdf56c2b9%40inbox.ru Author: Anton A. Melnikov Reviewed-by: Kyotaro Horiguchi, Alexander Korotkov
* pgbench: Fix overflow in table populating when rows >= 2^31-1Michael Paquier2023-12-24
| | | | | | | | | | | | Using a scale factor large enough so as the number of rows to insert gets larger than INT32_MAX would cause an infinite loop in initPopulateTable(), preventing pgbench to finish its initialization. Oversight in e35cc3b3f2d0 that has refactored the data generation logic. Author: John Hsu Reviewed-by: Tatsuo Ishii, Japin Li Discussion: https://postgr.es/m/CA+-JvFvHsOafjHcuFPfkyouHNZvbOXhBNhwZxKm3WNgYz9bwzA@mail.gmail.com
* Set readline-relevant ENV vars in interactive_psql(), not caller.Tom Lane2023-12-23
| | | | | | | | | | | | | | | | Commit 664d75753 pulled 010_tab_completion.pl's infrastructure for invoking an interactive psql session out into a generally-useful test function, but it didn't move enough stuff. We need to set up various environment variables that readline will look at, both to ensure stability of test results and to prevent test actions from cluttering the calling user's ~/.psql_history. Expecting calling scripts to remember to do that is too failure-prone: the other existing caller 001_password.pl did not do it. Hence, remove those initialization steps from 010_tab_completion.pl and put them into interactive_psql(). Since interactive_psql was already making a local ENV hash, this has no effect on calling scripts. Discussion: https://postgr.es/m/794610.1703182896@sss.pgh.pa.us
* Set all variable-length fields of pg_attribute to null on column dropPeter Eisentraut2023-12-22
| | | | | | | | | | | | | | When a column is dropped, the fields attacl, attoptions, and attfdwoptions were kept unchanged. This is probably harmless, but it seems wasteful, and leaves potentially dangling data lying around (for example, attacl could contain references to users that are later also dropped). Change this to set those fields to null when a column is marked as dropped. Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org> Discussion: https://www.postgresql.org/message-id/flat/249d819d-1763-4580-8110-0bf91a0f08b7@eisentraut.org
* Stop generating plain-text INSTALL instructions.Tom Lane2023-12-22
| | | | | | | | | | | | | | | | | | | | Up to now, our distribution tarballs have included a plain-text form of the installation.sgml chapter. The rationale for that was that a recipient might not have either ready internet access or HTML-viewing tools; a theory that seems downright quaint today. Maintaining the ability to generate this file is not without cost, because it puts special requirements on installation.sgml that are often overlooked. Moreover, we are moving in the direction of making our distribution tarballs be pure git snapshots for traceability/reproducibility reasons; including generated files doesn't fit into that plan. Hence, let's just drop INSTALL and remove the infrastructure for generating it. The top-level README will now recommend visiting our website to see the installation instructions. As a useful side-effect, we can get rid of README.git which has provoked confusion. Discussion: https://postgr.es/m/20231220114927.faccqqprmuyrzdip@alap3.anarazel.de Discussion: https://postgr.es/m/e07408d9-e5f2-d9fd-5672-f53354e9305e@eisentraut.org
* Make win32tzlist.pl checkable againAndrew Dunstan2023-12-22
| | | | | | | | | | Commit 1301c80b21 removed some infrastructure needed to check windows-oriented perl scripts. It also removed most such scripts, but this one was left over. We repair the damage by making Win32::Registry a conditional requirement that is only loaded on Windows. With this change `perl -cw win32tzlist.pl` once again passes on non-Windows machines. Discussion: https://postgr.es/m/a2bd77fd-61b8-4c2b-b12e-3e22ae260f82@eisentraut.org
* Initialize data directories with --lc-messages=C for tests.Jeff Davis2023-12-21
| | | | | | | Commit db6d9891e8 changed them to be initialized with --no-locale, but that reduced the test coverage for non-C locales. Discussion: https://postgr.es/m/0d47e5ecc037b3908149aad5f2a987793cf938bd.camel%40j-davis.com
* Replace nonsense comment with a relevant one.Robert Haas2023-12-21
| | | | | | Per report from Alexander Lakhin. Discussion: http://postgr.es/m/061cccf7-0cac-804f-4c2a-9d6da8e3848b@gmail.com
* Fix numerous typos in incremental backup commits.Robert Haas2023-12-21
| | | | | | | | | Apparently, spell check would have been a really good idea. Alexander Lakhin, with a few additions as per an off-list report from Andres Freund. Discussion: http://postgr.es/m/f08f7c60-1ad3-0b57-d580-54b11f07cddf@gmail.com
* pg_combinebackup didn't clean its tmp_check directory, either.Tom Lane2023-12-21
| | | | | | | Another oversight in dc2123400, visible when building/testing in the source directory. (There's a lot of stuff we could simplify if we stop supporting that case, but for now it's still mainstream.)
* Avoid trying to fetch metapage of an SPGist partitioned index.Tom Lane2023-12-21
| | | | | | | | | | | | | | | | | | | This is necessary when spgcanreturn() is invoked on a partitioned index, and the failure might be reachable in other scenarios as well. The rest of what spgGetCache() does is perfectly sensible for a partitioned index, so we should allow it to go through. I think the main takeaway from this is that we lack sufficient test coverage for non-btree partitioned indexes. Therefore, I added simple test cases for brin and gin as well as spgist (hash and gist AMs were covered already in indexing.sql). Per bug #18256 from Alexander Lakhin. Although the known test case only fails since v16 (3c569049b), I've got no faith at all that there aren't other ways to reach this problem; so back-patch to all supported branches. Discussion: https://postgr.es/m/18256-0b0e1b6e4a620f1b@postgresql.org
* pg_combinebackup's .gitignore file is incomplete.Tom Lane2023-12-21
| | | | Oversight in commit dc2123400, evidently.
* Fix BEFORE ROW trigger handling in cross-partition MERGE update.Dean Rasheed2023-12-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix a bug during MERGE if a cross-partition update is attempted on a partitioned table with a BEFORE DELETE ROW trigger that returns NULL, to prevent the update. This would cause an error to be thrown, or an assert failure in an assert-enabled build. This was an oversight in 9321c79c86, which failed to properly distinguish a DELETE prevented by a trigger from one prevented by a concurrent update. Fix by having ExecDelete() return the TM_Result status to ExecCrossPartitionUpdate(), so that it can distinguish the two cases, and make ExecCrossPartitionUpdate() return the TM_Result status to ExecUpdateAct(), so that it can return the correct status from a concurrent update. In addition, ensure that the command tag is correctly updated by having ExecMergeMatched() pass canSetTag to ExecUpdateAct(), rather than passing false, so that it updates the command tag if it does a cross-partition update, making this code path in ExecMergeMatched() consistent with ExecUpdate(). Per bug #18238 from Alexander Lakhin. Back-patch to v15, where MERGE was introduced. Dean Rasheed, reviewed by Richard Guo and Jian He. Discussion: https://postgr.es/m/18238-2f2bdc7f720180b9%40postgresql.org
* Fix prologue of get_partition_ancestors()Peter Eisentraut2023-12-21
| | | | | | | | | | The callers of this function assume that the first Oid in the list returned by this function corresponds to the immediate parent and the last on corresponds to the topmost parent. Make that explicit in the function prologue. Author: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> Discussion: https://www.postgresql.org/message-id/CAExHW5vCbATEmht861=G-BFPHNwLUqyeGa_=8-xibJ6Q1UxAeA@mail.gmail.com
* meson: Make gzip and tar optionalPeter Eisentraut2023-12-21
| | | | | | | They are only used for some tests. The tests are already set to skip as appropriate if they are not available. Discussion: https://www.postgresql.org/message-id/flat/ZQzp_VMJcerM1Cs_%40paquier.xyz
* meson: Make sed optionalPeter Eisentraut2023-12-21
| | | | | | | | | | | | | | | sed is used only if dtrace or selinux are enabled. Those options are only used on Unix platforms, which should have sed. But we don't want to make sed a hard requirement on Windows, which was the case in meson until now. This just changes sed to be not-required by meson. If you happen to use a system with, say, dtrace but without sed, you might get a slightly complicated error from meson during the build, but that seems better than making the requiredness a complicated conditional that will need to be maintained. Discussion: https://www.postgresql.org/message-id/flat/ZQzp_VMJcerM1Cs_%40paquier.xyz