aboutsummaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAge
...
* fix silly perl error in commit d064afc720Andrew Dunstan2021-04-21
|
* Only ever test for non-127.0.0.1 addresses on Windows in PostgresNodeAndrew Dunstan2021-04-21
| | | | | | | | | | This has been found to cause hangs where tcp usage is forced. Alexey Kodratov Discussion: https://postgr.es/m/82e271a9a11928337fcb5b5e57b423c0@postgrespro.ru Backpatch to all live branches
* Add DISTINCT to information schema usage viewsPeter Eisentraut2021-04-21
| | | | | | | | | | Since pg_depend can contain duplicate entries, we need to eliminate those in information schema views that build on pg_depend, using DISTINCT. Some of the older views already did that correctly, but some of the more recently added ones didn't. (In some of these views, it might not be possible to reproduce the issue because of how the implementation happens to deduplicate dependencies while recording them, but it seems better to keep this consistent in all cases.)
* Use correct format placeholder for timeline IDsPeter Eisentraut2021-04-21
| | | | Should be %u rather than %d.
* doc: Improve hyphenation consistencyPeter Eisentraut2021-04-21
|
* Don't use INT64_FORMAT inside message stringsPeter Eisentraut2021-04-21
| | | | Use %lld and cast to long long int instead.
* Fix typoPeter Eisentraut2021-04-21
|
* Add CURRENT_ROLE to list of roles for tab completion of GRANT in psqlMichael Paquier2021-04-21
| | | | | | | | This compatibility has been added in 45b9805, but psql forgot the call. Author: Wei Wang Reviewed-by: Aleksander Alekseev Discussion: https://postgr.es/m/OS3PR01MB6275935F62E161BCD393D6559E489@OS3PR01MB6275.jpnprd01.prod.outlook.com
* Improve WAL record descriptions for SP-GiST records.Tom Lane2021-04-20
| | | | | | While tracking down the bug fixed in the preceding commit, I got quite annoyed by the low quality of spg_desc's output. Add missing fields, try to make the formatting consistent.
* Fix under-parenthesized XLogRecHasBlockRef() macro.Tom Lane2021-04-20
| | | | | | | | | | | | | Commit f003d9f87 left this macro with inadequate (or, one could say, too much) parenthesization. Which was catastrophic to the correctness of calls such as "if (!XLogRecHasBlockRef(record, 1)) ...". There are only a few of those, which perhaps explains why we didn't notice immediately (with our general weakness of WAL replay testing being another factor). I found it by debugging intermittent replay failures like 2021-04-08 14:33:30.191 EDT [29463] PANIC: failed to locate backup block with ID 1 2021-04-08 14:33:30.191 EDT [29463] CONTEXT: WAL redo at 0/95D3438 for SPGist/ADD_NODE: off 1; blkref #0: rel 1663/16384/25998, blk 1
* Fix interaction of log_line_prefix's query_id and log_statementBruce Momjian2021-04-20
| | | | | | | | | | | log_statement is issued before query_id can be computed, so properly clear the value, and document the interaction. Reported-by: Fujii Masao, Michael Paquier Discussion: https://postgr.es/m/YHPkU8hFi4no4NSw@paquier.xyz Author: Julien Rouhaud
* adjust query id feature to use pg_stat_activity.query_idBruce Momjian2021-04-20
| | | | | | | | | | | Previously, it was pg_stat_activity.queryid to match the pg_stat_statements queryid column. This is an adjustment to patch 4f0b0966c8. This also adjusts some of the internal function calls to match. Catversion bumped. Reported-by: Álvaro Herrera, Julien Rouhaud Discussion: https://postgr.es/m/20210408032704.GA7498@alvherre.pgsql
* Rename find_em_expr_usable_for_sorting_rel.Tom Lane2021-04-20
| | | | | | | | | | | I didn't particularly like this function name, as it fails to express what's going on. Also, returning the sort expression alone isn't too helpful --- typically, a caller would also need some other fields of the EquivalenceMember. But the sole caller really only needs a bool result, so let's make it "bool relation_can_be_sorted_early()". Discussion: https://postgr.es/m/91f3ec99-85a4-fa55-ea74-33f85a5c651f@swarm64.com
* Fix planner failure in some cases of sorting by an aggregate.Tom Lane2021-04-20
| | | | | | | | | | | | | | | | | | | | | | | An oversight introduced by the incremental-sort patches caused "could not find pathkey item to sort" errors in some situations where a sort key involves an aggregate or window function. The basic problem here is that find_em_expr_usable_for_sorting_rel isn't properly modeling what prepare_sort_from_pathkeys will do later. Rather than hoping we can keep those functions in sync, let's refactor so that they actually share the code for identifying a suitable sort expression. With this refactoring, tlist.c's tlist_member_ignore_relabel is unused. I removed it in HEAD but left it in place in v13, in case any extensions are using it. Per report from Luc Vlaming. Back-patch to v13 where the problem arose. James Coleman and Tom Lane Discussion: https://postgr.es/m/91f3ec99-85a4-fa55-ea74-33f85a5c651f@swarm64.com
* Avoid unfortunate IPC::Run path caching in PostgresNodeAndrew Dunstan2021-04-20
| | | | | | | | | | | | | | | Commit b34ca595ab provided for installation-aware instances of PostgresNode. However, it turns out that IPC::Run works against this by caching the path to a binary and not consulting the path again, even if it has changed. We work around this by calling Postgres binaries with the installed path rather than just a bare name to be looked up in the environment path, if there is an installed path. For the common case where there is no installed path we continue to use the bare command name. Diagnosis and solution from Mark Dilger Discussion: https://postgr.es/m/E8F512F8-B4D6-4514-BA8D-2E671439DA92@enterprisedb.com
* Fix typo in commentMagnus Hagander2021-04-20
| | | | | | Author: Julien Rouhaud Backpatch-through: 11 Discussion: https://postgr.es/m/20210420121659.odjueyd4rpilorn5@nol
* Document LP_DEAD accounting issues in VACUUM.Peter Geoghegan2021-04-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | Document VACUUM's soft assumption that any LP_DEAD items encountered during pruning will become LP_UNUSED items before VACUUM finishes up. This is integral to the accounting used by VACUUM to generate its final report on the table to the stats collector. It also affects how VACUUM determines which heap pages are truncatable. In both cases VACUUM is concerned with the likely contents of the page in the near future, not the current contents of the page. This state of affairs created the false impression that VACUUM's dead tuple accounting had significant difference with similar accounting used during ANALYZE. There were and are no substantive differences, at least when the soft assumption completely works out. This is far clearer now. Also document cases where things don't quite work out for VACUUM's dead tuple accounting. It's possible that a significant number of LP_DEAD items will be left behind by VACUUM, and won't be recorded as remaining dead tuples in VACUUM's statistics collector report. This behavior dates back to commit a96c41fe, which taught VACUUM to run without index and heap vacuuming at the user's request. The failsafe mechanism added to VACUUM more recently by commit 1e55e7d1 takes the same approach to dead tuple accounting. Reported-By: Masahiko Sawada <sawada.mshk@gmail.com> Discussion: https://postgr.es/m/CAH2-Wz=Jmtu18PrsYq3EvvZJGOmZqSO2u3bvKpx9xJa5uhNp=Q@mail.gmail.com
* Use correct format placeholder for pidsPeter Eisentraut2021-04-19
| | | | Should be signed, not unsigned.
* Fix test case added by commit f5fc2f5b23.Amit Kapila2021-04-19
| | | | | | | | | | | | | | | | | In the new test after resetting the stats, we were not waiting for the stats message to be delivered. Also, we need to decode the results for the new test, otherwise, it will show the old stats. In passing, a. Change docs added by commit f5fc2f5b23 as per suggestion by Justin Pryzby. b. Bump the PGSTAT_FILE_FORMAT_ID as commit f5fc2f5b23 changes the file format of stats. Reported-by: Tom Lane based on buildfarm reports Author: Vignesh C, Justin Pryzby Reviewed-by: Amit Kapila Discussion: https://postgr.es/m/20210319185247.ldebgpdaxsowiflw@alap3.anarazel.de
* Fix typos and grammar in comments and docsMichael Paquier2021-04-19
| | | | | Author: Justin Pryzby Discussion: https://postgr.es/m/20210416070310.GG3315@telsasoft.com
* Replace magic constants for seek() calls in perl scriptsMichael Paquier2021-04-19
| | | | | | | | | | A couple of tests have been using 0 as magic constant while SEEK_SET can be used instead. This makes the code easier to understand, and more consistent with the changes done in 3c5b068. Per discussion with Andrew Dunstan. Discussion: https://postgr.es/m/YHrc24AgJQ6tQ1q0@paquier.xyz
* Explain postmaster's treatment of SIGURG.Thomas Munro2021-04-19
| | | | | | | | Add a few words of comment to explain why SIGURG doesn't follow the dummy_handler pattern used for SIGUSR2, since that might otherwise appear to be a bug. Discussion: https://postgr.es/m/4006115.1618577212%40sss.pgh.pa.us
* Add missing source files to nls.mkPeter Eisentraut2021-04-18
|
* Use correct format placeholder for block numbersPeter Eisentraut2021-04-17
| | | | Should be %u rather than %d.
* Rethink extraction of collation dependencies.Tom Lane2021-04-16
| | | | | | | | | | | | | | | | | | | | | | | As it stands, find_expr_references_walker() pays attention to leaf-node collation fields while ignoring the input collations of actual function and operator nodes. That seems exactly backwards from a semantic standpoint, and it leads to reporting dependencies on collations that really have nothing to do with the expression's behavior. Hence, rewrite to look at function input collations instead. This isn't completely perfect either; it fails to account for the behavior of record_eq and its siblings. (The previous coding at least gave an approximation of that, though I think it could be fooled pretty easily into considering the columns of irrelevant composite types.) We may be able to improve on this later, but for now this should satisfy the buildfarm members that didn't like ef387bed8. In passing fix some oversights in GetTypeCollations(), and get rid of its duplicative de-duplications. (I'm worried that it's still potentially O(N^2) or worse, but this makes it a little better.) Discussion: https://postgr.es/m/3564817.1618420687@sss.pgh.pa.us
* Update dummy prosrc values.Tom Lane2021-04-16
| | | | | | | | | | Ooops, forgot to s/system_views.sql/system_functions.sql/g in this part of 767982e36. No need for an additional catversion bump, I think, since these strings are gone by the time initdb finishes. Discussion: https://postgr.es/m/3956760.1618529139@sss.pgh.pa.us
* Convert built-in SQL-language functions to SQL-standard-body style.Tom Lane2021-04-16
| | | | | | | | | | | | | | Adopt the new pre-parsed representation for all built-in and information_schema SQL-language functions, except for a small number that can't presently be converted because they have polymorphic arguments. This eliminates residual hazards around search-path safety of these functions, and might provide some small performance benefits by reducing parsing costs. It seems useful also to provide more test coverage for the SQL-standard-body feature. Discussion: https://postgr.es/m/3956760.1618529139@sss.pgh.pa.us
* Split function definitions out of system_views.sql into a new file.Tom Lane2021-04-16
| | | | | | | | | | | | Invent system_functions.sql to carry the function definitions that were formerly in system_views.sql. The function definitions were already a quarter of the file and are about to be more, so it seems appropriate to give them their own home. In passing, fix an oversight in dfb75e478: it neglected to call check_input() for system_constraints.sql. Discussion: https://postgr.es/m/3956760.1618529139@sss.pgh.pa.us
* Allow TestLib::slurp_file to skip contents, and use as neededAndrew Dunstan2021-04-16
| | | | | | | | | | | | | | | | | | | In order to avoid getting old logfile contents certain functions in PostgresNode were doing one of two things. On Windows it rotated the logfile and restarted the server, while elsewhere it truncated the log file. Both of these are unnecessary. We borrow from the buildfarm which does this instead: note the size of the logfile before we start, and then when fetching the logfile skip to that position before accumulating contents. This is spelled differently on Windows but the effect is the same. This is largely centralized in TestLib's slurp_file function, which has a new optional parameter, the offset to skip to before starting to reading the file. Code in the client becomes much neater. Backpatch to all live branches. Michael Paquier, slightly modified by me. Discussion: https://postgr.es/m/YHajnhcMAI3++pJL@paquier.xyz
* Fix bogus collation-version-recording logic.Tom Lane2021-04-16
| | | | | | | | | | | | | | | | | | | | | | | | | | recordMultipleDependencies had the wrong scope for its "version" variable, allowing a version label to leak from the collation entry it was meant for to subsequent non-collation entries. This is relatively hard to trigger because of the OID-descending order that the inputs will normally arrive in: subsequent non-collation items will tend to be pinned. But it can be exhibited easily with a custom collation. Also, don't special-case the default collation, but instead ignore pinned-ness of a collation when we've found a version for it. This avoids creating useless pg_depend entries, and removes a not-very- future-proof assumption that C, POSIX, and DEFAULT are the only pinned collations. A small problem is that, because the default collation may or may not have a version, the regression tests can't assume anything about whether dependency entries will be made for it. This seems OK though since it's now handled just the same as other collations, and we have test cases for both versioned and unversioned collations. Fixes oversights in commit 257836a75. Thanks to Julien Rouhaud for review. Discussion: https://postgr.es/m/3564817.1618420687@sss.pgh.pa.us
* Fix wrong units in two ExplainPropertyFloat calls.Tom Lane2021-04-16
| | | | | | | | | | This is only a latent bug, since these calls are only reached for non-text output formats, and currently none of those will print the units. Still, we should get it right in case that ever changes. Justin Pryzby Discussion: https://postgr.es/m/20210415163846.GA3315@telsasoft.com
* psql: Refine lexing of BEGIN...END blocks in CREATE FUNCTION statementsPeter Eisentraut2021-04-16
| | | | | | | | Only track BEGIN...END blocks if they are in a CREATE [OR REPLACE] {FUNCTION|PROCEDURE} statement. Ignore if in parentheses. Reviewed-by: Laurenz Albe <laurenz.albe@cybertec.at> Discussion: https://www.postgresql.org/message-id/cee01d26fe55bc086b3bcf10bfe4e8d450e2f608.camel@cybertec.at
* psql: Small fixes for better translatabilityPeter Eisentraut2021-04-16
|
* Add information of total data processed to replication slot stats.Amit Kapila2021-04-16
| | | | | | | | | | | | This adds the statistics about total transactions count and total transaction data logically sent to the decoding output plugin from ReorderBuffer. Users can query the pg_stat_replication_slots view to check these stats. Suggested-by: Andres Freund Author: Vignesh C and Amit Kapila Reviewed-by: Sawada Masahiko, Amit Kapila Discussion: https://postgr.es/m/20210319185247.ldebgpdaxsowiflw@alap3.anarazel.de
* Provide query source text when parsing a SQL-standard function body.Tom Lane2021-04-15
| | | | | | | Without this, we lose error cursor positions, as shown in the modified regression test result. Discussion: https://postgr.es/m/2197698.1617984583@sss.pgh.pa.us
* Revert "Cope with NULL query string in ExecInitParallelPlan()."Tom Lane2021-04-15
| | | | | | | | This reverts commit b3ee4c503872f3d0a5d6a7cbde48815f555af15b. We don't need it in the wake of the preceding commit, which added an upstream check that the querystring isn't null. Discussion: https://postgr.es/m/2197698.1617984583@sss.pgh.pa.us
* Undo decision to allow pg_proc.prosrc to be NULL.Tom Lane2021-04-15
| | | | | | | | | | | | | | | | | | | | | | | | Commit e717a9a18 changed the longstanding rule that prosrc is NOT NULL because when a SQL-language function is written in SQL-standard style, we don't currently have anything useful to put there. This seems a poor decision though, as it could easily have negative impacts on external PLs (opening them to crashes they didn't use to have, for instance). SQL-function-related code can just as easily test "is prosqlbody not null" as "is prosrc null", so there's no real gain there either. Hence, revert the NOT NULL marking removal and adjust related logic. For now, we just put an empty string into prosrc for SQL-standard functions. Maybe we'll have a better idea later, although the history of things like pg_attrdef.adsrc suggests that it's not easy to maintain a string equivalent of a node tree. This also adds an assertion that queryDesc->sourceText != NULL to standard_ExecutorStart. We'd been silently relying on that for awhile, so let's make it less silent. Also fix some overlooked documentation and test cases. Discussion: https://postgr.es/m/2197698.1617984583@sss.pgh.pa.us
* Stabilize recently-added information_schema test queries.Tom Lane2021-04-15
| | | | | | | | | | | These queries could show unexpected entries if the core system, or concurrently-running test scripts, created any functions that would appear in the information_schema views. Restrict them to showing functions belonging to this test's schema, as the far-older nearby test case does. Per experimentation with conversion of some built-in functions to SQL-function-body style.
* Revert "psql: Show all query results by default"Peter Eisentraut2021-04-15
| | | | | | | | | This reverts commit 3a5130672296ed4e682403a77a9a3ad3d21cef75. Per discussion, this patch had too many issues to resolve at this point of the development cycle. We'll try again in the future. Discussion: https://www.postgresql.org/message-id/flat/alpine.DEB.2.21.1904132231510.8961@lancre
* pg_upgrade: Small fix for better translatability of help outputPeter Eisentraut2021-04-15
|
* Tweak behavior of pg_dump --extension with configuration tablesMichael Paquier2021-04-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | 6568cef, that introduced the option, had an inconsistent behavior when it comes to configuration tables set up by pg_extension_config_dump, as the data of all configuration tables would included in a dump even for extensions not listed by a set of --extension switches. The contents dumped changed depending on the schema where an extension was installed when an extension was not listed. For example, an extension installed under the public schema would have its configuration data not dumped even when not listed with --extension, which was inconsistent with the case of an extension installed on a non-public schema, where the configuration would be dumped. Per discussion with Noah, we have settled down to the simple rule of dumping configuration data of an extension if it is listed in --extension (default is unchanged and backward-compatible, to dump everything on sight if there are no extensions directly listed). This avoids some weird cases where the dumps depended on a --schema for one. More tests are added to cover the gap, where we cross-check more behaviors depending on --schema when an extension is not listed. Reported-by: Noah Misch Reviewed-by: Noah Misch Discussion: https://postgr.es/m/20210404220802.GA728316@rfd.leadboat.com
* Fix obsolete comments referencing JoinPathExtraData.extra_lateral_rels.Tom Lane2021-04-14
| | | | | | | | | | That field went away in commit edca44b15, but it seems that commit 45be99f8c re-introduced some comments mentioning it. Noted by James Coleman, though this isn't exactly his proposed new wording. Also thanks to Justin Pryzby for software archaeology. Discussion: https://postgr.es/m/CAAaqYe8fxZjq3na+XkNx4C78gDqykH-7dbnzygm9Qa9nuDTePg@mail.gmail.com
* amcheck: Reword some messages and fix an alignment problem.Robert Haas2021-04-14
| | | | | | | | | | | | | | | | We don't need to mention the attribute number in these messages, because there's a dedicated column for that, but we should mention the toast value ID, because that's really useful for any follow-up troubleshooting the user wants to do. This also rewords some of the messages to hopefully read a little better. Also, use VARATT_EXTERNAL_GET_POINTER in case we're accessing a TOAST pointer that isn't aligned on a platform that's fussy about alignment, so that we don't crash while corruption-checking the user's data. Mark Dilger, reviewed by me. Discussion: http://postgr.es/m/7D3B9BF6-50D0-4C30-8506-1C1851C7F96F@enterprisedb.com
* Improve quoting in some error messagesPeter Eisentraut2021-04-14
|
* doc: Move force_parallel_mode to section for developer optionsMichael Paquier2021-04-14
| | | | | | | | | | | | | | | | | | | | This GUC has always been classified as a planner option since its introduction in 7c944bd, and was listed in postgresql.conf.sample. As this parameter exists for testing purposes, move it to the section dedicated to developer parameters and hence remove it from postgresql.conf.sample. This will avoid any temptation to play with it on production servers for users that should never really have to touch this parameter. The general description used for developer options is reworded a bit, to take into account the inclusion of force_parallel_mode, per a suggestion from Tom Lane. Per discussion between Tom Lane, Bruce Momjian, Justin Pryzby, Bharath Rupireddy and me. Author: Justin Pryzby, Tom Lane Discussion: https://postgr.es/m/20210403152402.GA8049@momjian.us
* Use NameData datatype for slotname in stats.Amit Kapila2021-04-14
| | | | | | | | | | | This will make it consistent with the other usage of slotname in the code. In the passing, change pgstat_report_replslot signature to use a structure rather than multiple parameters. Reported-by: Andres Freund Author: Vignesh C Reviewed-by: Sawada Masahiko, Amit Kapila Discussion: https://postgr.es/m/20210319185247.ldebgpdaxsowiflw@alap3.anarazel.de
* Initialize t_self and t_tableOid in statext_expressions_loadTomas Vondra2021-04-14
| | | | | | | | The function is building a fake heap tuple, but left some of the header fields (tid and table OID) uninitialized. Per Coverity report. Reported-by: Ranier Vilela Discussion: https://postgr.es/m/CAEudQApj6h8tZ0-eP5Af5PKc5NG1YUc7=SdN_99YoHS51fKa0Q@mail.gmail.com
* Don't truncate heap when VACUUM's failsafe is in effect.Peter Geoghegan2021-04-13
| | | | | | | | | | | | It seems like a good idea to bypass heap truncation when the wraparound failsafe mechanism (which was added in commit 1e55e7d1) is in effect. Deliberately don't bypass heap truncation in the INDEX_CLEANUP=off case, even though it is similar to the failsafe case. There is already a separate reloption (and related VACUUM parameter) for that. Reported-By: Masahiko Sawada <sawada.mshk@gmail.com> Discussion: https://postgr.es/m/CAD21AoDWRh6oTN5T8wa+cpZUVpHXET8BJ8Da7WHVHpwkPP6KLg@mail.gmail.com
* Allow table-qualified variable names in ON CONFLICT ... WHERE.Tom Lane2021-04-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously you could only use unqualified variable names here. While that's not a functional deficiency, since only the target table can be referenced, it's a surprising inconsistency with the rules for partial-index predicates, on which this syntax is supposedly modeled. The fix for that is no harder than passing addToRelNameSpace = true to addNSItemToQuery. However, it's really pretty bogus for transformOnConflictArbiter and transformOnConflictClause to be messing with the namespace item for the target table at all. It's not theirs to manage, it results in duplicative creations of namespace items, and transformOnConflictClause wasn't even doing it quite correctly (that coding resulted in two nsitems for the target table, since it hadn't cleaned out the existing one). Hence, make transformInsertStmt responsible for setting up the target nsitem once for both these clauses and RETURNING. Also, arrange for ON CONFLICT ... UPDATE's "excluded" pseudo-relation to be added to the rangetable before we run transformOnConflictArbiter. This produces a more helpful HINT if someone writes "excluded.col" in the arbiter expression. Per bug #16958 from Lukas Eder. Although I agree this is a bug, the consequences are hardly severe, so no back-patch. Discussion: https://postgr.es/m/16958-963f638020de271c@postgresql.org
* Fix some inappropriately-disallowed uses of ALTER ROLE/DATABASE SET.Tom Lane2021-04-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Most GUC check hooks that inspect database state have special checks that prevent them from throwing hard errors for state-dependent issues when source == PGC_S_TEST. This allows, for example, "ALTER DATABASE d SET default_text_search_config = foo" when the "foo" configuration hasn't been created yet. Without this, we have problems during dump/reload or pg_upgrade, because pg_dump has no idea about possible dependencies of GUC values and can't ensure a safe restore ordering. However, check_role() and check_session_authorization() hadn't gotten the memo about that, and would throw hard errors anyway. It's not entirely clear what is the use-case for "ALTER ROLE x SET role = y", but we've now heard two independent complaints about that bollixing an upgrade, so apparently some people are doing it. Hence, fix these two functions to act more like other check hooks with similar needs. (But I did not change their insistence on being inside a transaction, as it's still not apparent that setting either GUC from the configuration file would be wise.) Also fix check_temp_buffers, which had a different form of the disease of making state-dependent checks without any exception for PGC_S_TEST. A cursory survey of other GUC check hooks did not find any more issues of this ilk. (There are a lot of interdependencies among PGC_POSTMASTER and PGC_SIGHUP GUCs, which may be a bad idea, but they're not relevant to the immediate concern because they can't be set via ALTER ROLE/DATABASE.) Per reports from Charlie Hornsby and Nathan Bossart. Back-patch to all supported branches. Discussion: https://postgr.es/m/HE1P189MB0523B31598B0C772C908088DB7709@HE1P189MB0523.EURP189.PROD.OUTLOOK.COM Discussion: https://postgr.es/m/20160711223641.1426.86096@wrigleys.postgresql.org
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-05 16:18:29 +0000