aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAge
* Handle NULL for short descriptions of custom GUC variablesMichael Paquier2022-05-28
| | | | | | | | | | | | | | | If a short description is specified as NULL in one of the various DefineCustomXXXVariable() functions available to external modules to define a custom parameter, SHOW ALL would crash. This change teaches SHOW ALL to properly handle NULL short descriptions, as well as any code paths that manipulate it, to gain in flexibility. Note that help_config.c was already able to do that, when describing a set of GUCs for postgres --describe-config. Author: Steve Chavez Reviewed by: Nathan Bossart, Andres Freund, Michael Paquier, Tom Lane Discussion: https://postgr.es/m/CAGRrpzY6hO-Kmykna_XvsTv8P2DshGiU6G3j8yGao4mk0CqjHA%40mail.gmail.com Backpatch-through: 10
* Teach remove_unused_subquery_outputs about window run conditionsDavid Rowley2022-05-27
| | | | | | | | | | | | | | | | | | | | | | | | | 9d9c02ccd added code to allow the executor to take shortcuts when quals on monotonic window functions guaranteed that once the qual became false it could never become true again. When possible, baserestrictinfo quals are converted to become these quals, which we call run conditions. Unfortunately, in 9d9c02ccd, I forgot to update remove_unused_subquery_outputs to teach it about these run conditions. This could cause a WindowFunc column which was unused in the target list but referenced by an upper-level WHERE clause to be removed from the subquery when the qual in the WHERE clause was converted into a window run condition. Because of this, the entire WindowClause would be removed from the query resulting in additional rows making it into the resultset when they should have been filtered out by the WHERE clause. Here we fix this by recording which target list items in the subquery have run conditions. That gets passed along to remove_unused_subquery_outputs to tell it not to remove these items from the target list. Bug: #17495 Reported-by: Jeremy Evans Reviewed-by: Richard Guo Discussion: https://postgr.es/m/17495-7ffe2fa0b261b9fa@postgresql.org
* Remove misguided SSL key file ownership check in libpq.Tom Lane2022-05-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commits a59c79564 et al. tried to sync libpq's SSL key file permissions checks with what we've used for years in the backend. We did not intend to create any new failure cases, but it turns out we did: restricting the key file's ownership breaks cases where the client is allowed to read a key file despite not having the identical UID. In particular a client running as root used to be able to read someone else's key file; and having seen that I suspect that there are other, less-dubious use cases that this restriction breaks on some platforms. We don't really need an ownership check, since if we can read the key file despite its having restricted permissions, it must have the right ownership --- under normal conditions anyway, and the point of this patch is that any additional corner cases where that works should be deemed allowable, as they have been historically. Hence, just drop the ownership check, and rearrange the permissions check to get rid of its faulty assumption that geteuid() can't be zero. (Note that the comparable backend-side code doesn't have to cater for geteuid() == 0, since the server rejects that very early on.) This does have the end result that the permissions safety check used for a root user's private key file is weaker than that used for anyone else's. While odd, root really ought to know what she's doing with file permissions, so I think this is acceptable. Per report from Yogendra Suralkar. Like the previous patch, back-patch to all supported branches. Discussion: https://postgr.es/m/MW3PR15MB3931DF96896DC36D21AFD47CA3D39@MW3PR15MB3931.namprd15.prod.outlook.com
* In CREATE FOREIGN TABLE syntax synopsis, fix partitioning stuff.Robert Haas2022-05-26
| | | | | | | | | Foreign tables can be partitioned, but previous documentation commits left the syntax synopsis both incomplete and incorrect. Justin Pryzby and Amit Langote Discussion: http://postgr.es/m/20220521130922.GX19626@telsasoft.com
* Avoid ERRCODE_INTERNAL_ERROR in oracle_compat.c functions.Tom Lane2022-05-26
| | | | | | | | | | | | | | | | | | | repeat() checked for integer overflow during its calculation of the required output space, but it just passed the resulting integer to palloc(). This meant that result sizes between 1GB and 2GB led to ERRCODE_INTERNAL_ERROR, "invalid memory alloc request size" rather than ERRCODE_PROGRAM_LIMIT_EXCEEDED, "requested length too large". That seems like a bit of a wart, so add an explicit AllocSizeIsValid check to make these error cases uniform. Do likewise in the sibling functions lpad() etc. While we're here, also modernize their overflow checks to use pg_mul_s32_overflow() etc instead of expensive divisions. Per complaint from Japin Li. This is basically cosmetic, so I don't feel a need to back-patch. Discussion: https://postgr.es/m/ME3P282MB16676ED32167189CB0462173B6D69@ME3P282MB1667.AUSP282.PROD.OUTLOOK.COM
* relnotes: update ordered partition scan itemBruce Momjian2022-05-25
| | | | | | Reported-by: Amit Langote Discussion: https://postgr.es/m/CA+HiwqFMmOK9cjrqxJeY1HKKbgMup0HcZ+Co7JuzJG_8ZypceA@mail.gmail.com
* Add tab completion for table_rewrite's CREATE EVENT TRIGGER in psqlMichael Paquier2022-05-25
| | | | | Author: Hou Zhijie Discussion: https://postgr.es/m/OS0PR01MB5716DEFF787B925C4778228C94D69@OS0PR01MB5716.jpnprd01.prod.outlook.com
* Fix stats_fetch_consistency default value indicated in postgresql.conf.sample.Andres Freund2022-05-24
| | | | | | | | | Mistake in 5891c7a8ed8, likely made when switching the default value from none to fetch during development. Reported-By: Nathan Bossart <nathandbossart@gmail.com> Author: Nathan Bossart <nathandbossart@gmail.com> Discussion: https://postgr.es/m/20220524220147.GA1298892@nathanxps13
* relnotes: add Heikki to UTF8 itemBruce Momjian2022-05-24
| | | | | | Reported-by: John Naylor Discussion: https://postgr.es/m/CAFBsxsFhbhMbK_ZaLpH6J8BfJL_uowtGg+Qs9XA=F4uPU3aucA@mail.gmail.com
* Remove duplicated words in comments of pgstat.c and pgstat_internal.hMichael Paquier2022-05-24
| | | | | | Author: Atsushi Torikoshi Reviewed-by: Nathan Bossart Discussion: https://postgr.es/m/d00ddbf29f9d09b3a471e64977560de1@oss.nttdata.com
* doc: Improve COPY synopsisPeter Eisentraut2022-05-23
| | | | | | | Upper-case MATCH so that it is clearer that it is a keyword in this context. Discussion: https://www.postgresql.org/message-id/flat/20220517.174342.1884842412165214815.horikyota.ntt%40gmail.com
* pg_upgrade: Tweak translatable stringsPeter Eisentraut2022-05-23
| | | | | | | | | "\r" (for progress output) must not be inside a translatable string (gettext gets upset). In passing, move the minimum supported version number to a separate argument, so that we don't have to retranslate this string every year now.
* doc: Add documentation for pg_database.datlocprovider columnPeter Eisentraut2022-05-23
| | | | | | | This was apparently missed in the original commit. Author: Shinoda, Noriyoshi (PN Japan FSIP) <noriyoshi.shinoda@hpe.com> Discussion: https://www.postgresql.org/message-id/flat/DM4PR84MB1734BA51BC8B08CF3FA239BBEED49%40DM4PR84MB1734.NAMPRD84.PROD.OUTLOOK.COM
* psql: Update \timing also in case of an errorPeter Eisentraut2022-05-23
| | | | | | | | | | | | | | | The changes to show all query results (7844c9918) broke \timing output in case of an error; it didn't update the timing result and showed 0.000 ms. Fix by updating the timing result also in the error case. Also, for robustness, update the timing result any time a result is obtained, not only for the last, so a sensible value is always available. Reported-by: Tom Lane <tgl@sss.pgh.pa.us> Author: Richard Guo <guofenglinux@gmail.com> Author: Fabien COELHO <coelho@cri.ensmp.fr> Discussion: https://www.postgresql.org/message-id/3813350.1652111765%40sss.pgh.pa.us
* Remove debug messages from tuplesort_sort_memtuples()John Naylor2022-05-23
| | | | | | | These were of value only during development. Reported by Justin Pryzby Discussion: https://www.postgresql.org/message-id/20220519201254.GU19626%40telsasoft.com
* pgstat: fix stats.spec instability on slow machines.Andres Freund2022-05-22
| | | | | | | | | | | | | | | On slow machines the modified test could end up switching the order in which transactional stats are reported in one session and non-transactional stats in another session. As stats handling of truncate is implemented as setting live/dead rows 0, the order in which a truncate's stats changes are applied, relative to normal stats updates, matters. The handling of stats for truncate hasn't changed due to shared memory stats, this is longstanding behavior. We might want to improve truncate's stats handling in the future, but for now just change the order of forced flushed to make the test stable. Reported-By: Christoph Berg <myon@debian.org> Discussion: https://postgr.es/m/YoZf7U/WmfmFYFEx@msg.df7cb.de
* Show 'AS "?column?"' explicitly when it's important.Tom Lane2022-05-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | ruleutils.c was coded to suppress the AS label for a SELECT output expression if the column name is "?column?", which is the parser's fallback if it can't think of something better. This is fine, and avoids ugly clutter, so long as (1) nothing further up in the parse tree relies on that column name or (2) the same fallback would be assigned when the rule or view definition is reloaded. Unfortunately (2) is far from certain, both because ruleutils.c might print the expression in a different form from how it was originally written and because FigureColname's rules might change in future releases. So we shouldn't rely on that. Detecting exactly whether there is any outer-level use of a SELECT column name would be rather expensive. This patch takes the simpler approach of just passing down a flag indicating whether there *could* be any outer use; for example, the output column names of a SubLink are not referenceable, and we also do not care about the names exposed by the right-hand side of a setop. This is sufficient to suppress unwanted clutter in all but one case in the regression tests. That seems like reasonable evidence that it won't be too much in users' faces, while still fixing the cases we need to fix. Per bug #17486 from Nicolas Lutic. This issue is ancient, so back-patch to all supported branches. Discussion: https://postgr.es/m/17486-1ad6fd786728b8af@postgresql.org
* Remove unused-and-misspelled function extern declaration.Tom Lane2022-05-21
| | | | | | | | | | | Commit c65507763 added "extern XLogRecPtr CalculateMaxmumSafeLSN(void)", which bears no trace of connection to anything else in that patch or anywhere else. Remove it again. Sergei Kornilov (also spotted by Bharath Rupireddy) Discussion: https://postgr.es/m/706501646056870@vla3-6a5326aeb4ee.qloud-c.yandex.net Discussion: https://postgr.es/m/CALj2ACVoQ7NEf43Xz0rfxsGOKYTN5r4VZp2DO2_5p+CMzsRPFw@mail.gmail.com
* Avoid overflow hazard when clamping group counts to "long int".Tom Lane2022-05-21
| | | | | | | | | | | | | | | | | | | | | | | | Several places in the planner tried to clamp a double value to fit in a "long" by doing (long) Min(x, (double) LONG_MAX); This is subtly incorrect, because it casts LONG_MAX to double and potentially back again. If long is 64 bits then the double value is inexact, and the platform might round it up to LONG_MAX+1 resulting in an overflow and an undesirably negative output. While it's not hard to rewrite the expression into a safe form, let's put it into a common function to reduce the risk of someone doing it wrong in future. In principle this is a bug fix, but since the problem could only manifest with group count estimates exceeding 2^63, it seems unlikely that anyone has actually hit this or will do so anytime soon. We're fixing it mainly to satisfy fuzzer-type tools. That being the case, a HEAD-only fix seems sufficient. Andrey Lepikhov Discussion: https://postgr.es/m/ebbc2efb-7ef9-bf2f-1ada-d6ec48f70e58@postgrespro.ru
* doc: Mention pg_read_all_stats in description of track_activitiesMichael Paquier2022-05-21
| | | | | | | | | | | | | The description of track_activities mentioned that it is visible to superusers and that the information related to the current session can be seen, without telling about pg_read_all_stats. Roles that are granted the privileges of pg_read_all_stats can also see this information, so mention it in the docs. Author: Ian Barwick Reviewed-by: Nathan Bossart Discussion: https://postgr.es/m/CAB8KJ=jhPyYFu-A5r-ZGP+Ax715mUKsMxAGcEQ9Cx_mBAmrPow@mail.gmail.com Backpatch-through: 10
* doc: Fix description of the JIT time fields in pg_stat_statementsMichael Paquier2022-05-21
| | | | | | | | | | The four fields tracking the time spent by queries for JIT operations added in 57d6aea were listed as having bigint as data type, but these are of type double precision. Author: Noriyoshi Shinoda Reviewed-by: Nathan Bossart Discussion: https://postgr.es/m/DM4PR84MB1734375E63148AADC6A1E6B4EED39@DM4PR84MB1734.NAMPRD84.PROD.OUTLOOK.COM
* Improve and fix some issues in the TAP tests of pg_upgradeMichael Paquier2022-05-21
| | | | | | | | | | | | | | | | | | This is based on a set of suggestions from Noah, with the following changes made: - The set of databases created in the tests are now prefixed with "regression" to not trigger any warnings with name restrictions when compiling the code with -DENFORCE_REGRESSION_TEST_NAME_RESTRICTIONS, and now only the first name checks after the Windows case of double quotes mixed with backslashes. - Fix an issue with EXTRA_REGRESS_OPTS, which were not processed in a way consistent with 027_stream_regress.pl (missing space between the option string and pg_regress). This got introduced in 7dd3ee5. - Add a check on the exit code of the pg_regress command, to catch failures after running the regression tests. Reviewed-by: Noah Misch Discussion: https://postgr.es/m/YoHhWD5vQzb2mmiF@paquier.xyz
* Remove portability hazard in unsafe_tests/sql/guc_privs.sql.Tom Lane2022-05-20
| | | | | | | | | | | | This new-in-v15 test case assumed it could set max_stack_depth as high as 2MB. You might think that'd be true on any modern platform but you'd be wrong, as I found out while experimenting with NetBSD/hppa. This test is about privileges not platform capabilities, so there seems no need to use any value greater than the 100kB setting already used in a couple of places in the core regression tests. There's certainly no call to expect people to raise their platform's default ulimit just to run this test.
* Fix DDL deparse of CREATE OPERATOR CLASSAlvaro Herrera2022-05-20
| | | | | | | | | | | | | When an implicit operator family is created, it wasn't getting reported. Make it do so. This has always been missing. Backpatch to 10. Author: Masahiko Sawada <sawada.mshk@gmail.com> Reported-by: Leslie LEMAIRE <leslie.lemaire@developpement-durable.gouv.fr> Reviewed-by: Amit Kapila <amit.kapila16@gmail.com> Reviewed-by: Michael Paquiër <michael@paquier.xyz> Discussion: https://postgr.es/m/f74d69e151b22171e8829551b1159e77@developpement-durable.gouv.fr
* Add pg_version() to PostgreSQL::Test::ClusterMichael Paquier2022-05-20
| | | | | | | | | | | _pg_version (version number based on PostgreSQL::Version) is a field private to Cluster.pm but there was no helper routine to retrieve it from a Cluster's node. The same is done for install_path, for example, and the version object becomes handy when writing tests that need version-specific handling. Reviewed-by: Andrew Dunstan, Daniel Gustafsson Discussion: https://postgr.es/m/YoWfoJTc987tsxpV@paquier.xyz
* doc: Explain 'invalid' index state for CREATE INDEX CONCURRENTLYAlvaro Herrera2022-05-20
| | | | | | | | | | | | It wasn't previously mentioned that the index is created as invalid, which is confusing to new users. Backpatch to 14 (only because of a conflict in 13). Author: Laurenz Albe <laurenz.albe@cybertec.at> Reported-by: Lauren Fliksteen <dancernerd32@gmail.com> Reviewed-by: Rajakavitha Kodhandapani <krajakavitha@gmail.com> Discussion: https://postgr.es/m/165290238488.670.7500177735573254738@wrigleys.postgresql.org
* pg_waldump: Improve option parsing error messagesPeter Eisentraut2022-05-20
| | | | | | | | I rephrased the error messages to be more in the style of option_parse_int(), and also made use of the new "detail" message facility. I didn't actually use option_parse_int() (which could be used for -n) because libpgfeutils wasn't used here yet and I wanted to keep this just to string changes. But it could be done in the future.
* Doc: clarify location of libpq's default service file on Windows.Tom Lane2022-05-19
| | | | | | | | | | | | | | | | | | | | | The documentation didn't specify the name of the per-user service file on Windows, and extrapolating from the pattern used for other config files gave the wrong answer. The fact that it isn't consistent with the others sure seems like a bug, but it's far too late to change that now; we'd just penalize people who worked it out in the past. So, simply document the true state of affairs. In passing, fix some gratuitous differences between the discussions of the service file and the password file. Julien Rouhaud, per question from Dominique Devienne. Backpatch to all supported branches. I (tgl) also chose to back-patch the part of commit ba356a397 that touched libpq.sgml's description of the service file --- in hindsight, I'm not sure why I didn't do so at the time, as it includes some fairly essential information. Discussion: https://postgr.es/m/CAFCRh-_mdLrh8eYVzhRzu4c8bAFEBn=rwoHOmFJcQOTsCy5nig@mail.gmail.com
* Repurpose PROC_COPYABLE_FLAGS as PROC_XMIN_FLAGSAlvaro Herrera2022-05-19
| | | | | | | | | | | | | | | This is a slight, convenient semantics change from what commit 0f0cfb494004 ("Fix parallel operations that prevent oldest xmin from advancing") introduced that lets us simplify the coding in the one place where it is used. Backpatch to 13. This is related to commit 6fea65508a1a ("Tighten ComputeXidHorizons' handling of walsenders") rewriting the code site where this is used, which has not yet been backpatched, but it may well be in the future. Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com> Discussion: https://postgr.es/m/202204191637.eldwa2exvguw@alvherre.pgsql
* Rework SQL/JSON documentationAndrew Dunstan2022-05-19
| | | | | | | | | | This makes the documentation conform more closely the style of other function sections. Includes suggestions from Erik Rijkers, Alvaro Herrera, and Justin Pryzby. Discussion: https://postgr.es/m/CAKFQuwaq5Ny6d3nWbJo=QO4RmhSk9JD8zrkURLR-wWmB2Pkz7Q@mail.gmail.com
* doc: Properly punctuate "etc."Peter Eisentraut2022-05-19
|
* Fix incorrect comments for Memoize structDavid Rowley2022-05-19
| | | | | | Reported-by: Peter Eisentraut Discussion: https://postgr.es/m/0635f5aa-4973-8dc2-4e4e-df9fd5778a65@enterprisedb.com Backpatch-through: 14, where Memoize was added
* Extend pg_publication_tables to display column list and row filter.Amit Kapila2022-05-19
| | | | | | | | | | | | | | | Commit 923def9a53 and 52e4f0cd47 allowed to specify column lists and row filters for publication tables. This commit extends the pg_publication_tables view and pg_get_publication_tables function to display that information. This information will be useful to users and we also need this for the later commit that prohibits combining multiple publications with different column lists for the same table. Author: Hou Zhijie Reviewed By: Amit Kapila, Alvaro Herrera, Shi Yu, Takamichi Osumi Discussion: https://postgr.es/m/202204251548.mudq7jbqnh7r@alvherre.pgsql
* Update xml_1.out and xml_2.outAlvaro Herrera2022-05-18
| | | | Commit 0fbf01120023 should have updated them but didn't.
* Fix EXPLAIN MERGE output when no tuples are processedAlvaro Herrera2022-05-18
| | | | | | | | | An 'else' clause was misplaced in commit 598ac10be1c2, making zero-rows output look a bit silly. Add a test case for it. Pointed out by Tom Lane. Discussion: https://postgr.es/m/21030.1652893083@sss.pgh.pa.us
* Check column list length in XMLTABLE/JSON_TABLE aliasAlvaro Herrera2022-05-18
| | | | | | | | | | | | | | | | | We weren't checking the length of the column list in the alias clause of an XMLTABLE or JSON_TABLE function (a "tablefunc" RTE), and it was possible to make the server crash by passing an overly long one. Fix it by throwing an error in that case, like the other places that deal with alias lists. In passing, modify the equivalent test used for join RTEs to look like the other ones, which was different for no apparent reason. This bug came in when XMLTABLE was born in version 10; backpatch to all stable versions. Reported-by: Wang Ke <krking@zju.edu.cn> Discussion: https://postgr.es/m/17480-1c9d73565bb28e90@postgresql.org
* Make EXPLAIN MERGE output format more compactAlvaro Herrera2022-05-18
| | | | | | | | | | We can use a single line to print all tuple counts that MERGE processed, for conciseness, and elide those that are zeroes. Non-text formats report all numbers, as is typical. Per comment from Justin Pryzby <pryzby@telsasoft.com> Discussion: https://postgr.es/m/20220511163350.GL19626@telsasoft.com
* Fix markup in synopsisPeter Eisentraut2022-05-18
| | | | | | | | | There is no need for a <literal> inside a <synopsis>, since the latter is already all "literal" implicitly. Also, create_help.pl misparses it. So just remove it. Reported-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/20220517.174342.1884842412165214815.horikyota.ntt%40gmail.com
* pgbench: Restore compatibility of --partitions=0Michael Paquier2022-05-18
| | | | | | | | | | A value of 0 is allowed for this option since its creation, that would map with the default of having no partitions for pgbench_accounts, but 6f164e6 broke that by enforcing an error. This commit restores the original behavior. Author: Amit Langote Discussion: https://postgr.es/m/CA+HiwqGAGobiiHR8nH382HJxqm1mzZs8=3oKPXnXivWoFSZmNA@mail.gmail.com
* Fix typo in walreceiver.cMichael Paquier2022-05-18
| | | | | | | s/primary_slotname/primary_slot_name/. Author: Bharath Rupireddy Discussion: https://postgr.es/m/CALj2ACX3=pHkCpoGG-z+O=7Gp5YZv70jmfTyGnNV7YF3SkK73g@mail.gmail.com
* Stamp 15beta1.REL_15_BETA1Tom Lane2022-05-16
|
* relnotes: improve updated UTF8 item wordingBruce Momjian2022-05-16
|
* relnotes: improve UTF8 text item in relation to ASCIIBruce Momjian2022-05-16
| | | | | | Reported-by: John Naylor Discussion: https://postgr.es/m/CAFBsxsE-US0sgVxVHjt99GCGky4TCD57gwMHWPF9XWo7R5rXPg@mail.gmail.com
* Translation updatesPeter Eisentraut2022-05-16
| | | | | Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: dde45df385dab9032155c1f867b677d55695310c
* pg_upgrade: Add missing gettext triggersPeter Eisentraut2022-05-16
| | | | Forgot to add it in one place in the previous commit.
* pg_upgrade: Add missing gettext triggersPeter Eisentraut2022-05-16
| | | | prep_status_progress() is new.
* Fix incorrect row estimates used for Memoize costingDavid Rowley2022-05-16
| | | | | | | | | | | | | | | | | | | | | | | | | | In order to estimate the cache hit ratio of a Memoize node, one of the inputs we require is the estimated number of times the Memoize node will be rescanned. The higher this number, the large the cache hit ratio is likely to become. Unfortunately, the value being passed as the number of "calls" to the Memoize was incorrectly using the Nested Loop's outer_path->parent->rows instead of outer_path->rows. This failed to account for the fact that the outer_path might be parameterized by some upper-level Nested Loop. This problem could lead to Memoize plans appearing more favorable than they might actually be. It could also lead to extended executor startup times when work_mem values were large due to the planner setting overly large MemoizePath->est_entries resulting in the Memoize hash table being initially made much larger than might be required. Fix this simply by passing outer_path->rows rather than outer_path->parent->rows. Also, adjust the expected regression test output for a plan change. Reported-by: Pavel Stehule Author: David Rowley Discussion: https://postgr.es/m/CAFj8pRAMp%3DQsMi6sPQJ4W3hczoFJRvyXHJV3AZAZaMyTVM312Q%40mail.gmail.com Backpatch-through: 14, where Memoize was introduced
* Add link to HBA docs in initdb --auth documentationAlvaro Herrera2022-05-14
| | | | | | | Reaction to a suggestion from jhebert@micron.com, though this doesn't directly address the complaint. Discussion: https://postgr.es/m/165117307860.683.10308862820133754390@wrigleys.postgresql.org
* Add link to initdb in pg_hba.conf docsAlvaro Herrera2022-05-14
| | | | | | Suggested by David G. Johnston <david.g.johnston@gmail.com> Discussion: https://postgr.es/m/CAKFQuwYK4OqwoHscZi3yws-urv3NvVfoKHessyso5D=5qqChYQ@mail.gmail.com
* Fix slow animal timeouts in 032_relfilenode_reuse.pl.Thomas Munro2022-05-14
| | | | | | | | | | | | | | | | Per BF animal chipmunk: CREATE DATABASE could apparently fail due to an AV process being in the template database and not quitting fast enough for the 5 second timeout in CountOtherDBBackends(). The test script had autovacuum_naptime=1s to encourage more activity and opening of fds, but that wasn't strictly necessary for this test. Take it out. Per BF animal skink: there was a 300s timeout for all tests in the script, but apparently that was not enough under valgrind. Let's use the standard timeout $PostgreSQL::Test::Utils::timeout_default, but restart it for each query we run. Reviewed-by: Robert Haas <robertmhaas@gmail.com> Discussion: https://postgr.es/m/CA%2BhUKGKa8HNJaA24gqiiFoGy0ysndeVoJsHvX_q1-DVLFaGAmw%40mail.gmail.com
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-05 16:13:21 +0000