summaryrefslogtreecommitdiff
path: root/src/bin/pg_upgrade
AgeCommit message (Collapse)Author
2020-12-30In pg_upgrade cross-version test, handle lack of oldstyle_length().Noah Misch
This suffices for testing v12 -> v13; some other version pairs need more changes. Back-patch to v10, which removed the function.
2020-11-09Translation updatesPeter Eisentraut
Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: 2ffedf5ea37677f39cdc1eb92a1e78762cd3fb0e
2020-10-15pg_upgrade: remove C99 compiler req. from commit 3c0471b5fdBruce Momjian
This commit required support for inline variable definition, which is not a requirement. RELEASE NOTE AUTHOR: the author of commit 3c0471b5fd (pg_upgrade/tablespaces) was Justin Pryzby, not me. Reported-by: Andres Freund Discussion: https://postgr.es/m/20201016001959.h24fkywfubkv2pc5@alap3.anarazel.de Backpatch-through: 9.5
2020-10-15pg_upgrade: generate check error for left-over new tablespaceBruce Momjian
Previously, if pg_upgrade failed, and the user recreated the cluster but did not remove the new cluster tablespace directory, a later pg_upgrade would fail since the new tablespace directory would already exists. This adds error reporting for this during check. Reported-by: Justin Pryzby Discussion: https://postgr.es/m/20200925005531.GJ23631@telsasoft.com Backpatch-through: 9.5
2020-10-06pg_upgrade: remove pre-8.4 code and >= 8.4 checkBruce Momjian
We only support upgrading from >= 8.4 so no need for this code or tests. Reported-by: Magnus Hagander Discussion: https://postgr.es/m/CABUevEx-D0PNVe00tkeQRGennZQwDtBJn=493MJt-x6sppbUxA@mail.gmail.com Backpatch-through: 9.5
2020-10-06pg_upgrade; change major version comparisons to use <=, not <Bruce Momjian
This makes checking for older major versions more consistent. Backpatch-through: 9.5
2020-09-21Translation updatesPeter Eisentraut
Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: cdd5cffbddac2869f3eed0a6a37cba71ce2332cd
2020-09-14Translation updatesPeter Eisentraut
Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: 00c0d74fc1f1f2a831077fdf3655c6ae5eeceac3
2020-08-10Move connect.h from fe_utils to src/include/common.Noah Misch
Any libpq client can use the header. Clients include backend components postgres_fdw, dblink, and logical replication apply worker. Back-patch to v10, because another fix needs this. In released branches, just copy the header and keep the original.
2020-06-15pg_upgrade: set vacuum_defer_cleanup_age to zeroBruce Momjian
Non-zero vacuum_defer_cleanup_age values cause pg_upgrade freezing of the system catalogs to be incomplete, or do nothing. This will cause the upgrade to fail in confusing ways. Reported-by: Laurenz Albe Discussion: https://postgr.es/m/7d6f6c22ba05ce0c526e9e8b7bfa8105e7da45e6.camel@cybertec.at Backpatch-through: 9.5
2020-05-18Translation updatesPeter Eisentraut
Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: 031ca65d7825c3e539a3e62ea9d6630af12e6b6b
2020-05-11Translation updatesPeter Eisentraut
Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: 80d8f54b3c5533ec036404bd3c3b24ff4825d037
2020-03-28Enable Unix-domain sockets support on WindowsPeter Eisentraut
As of Windows 10 version 1803, Unix-domain sockets are supported on Windows. But it's not automatically detected by configure because it looks for struct sockaddr_un and Windows doesn't define that. So we just make our own definition on Windows and override the configure result. Set DEFAULT_PGSOCKET_DIR to empty on Windows so by default no Unix-domain socket is used, because there is no good standard location. In pg_upgrade, we have to do some extra tweaking to preserve the existing behavior of not using Unix-domain sockets on Windows. Adding support would be desirable, but it needs further work, in particular a way to select whether to use Unix-domain sockets from the command-line or with a run-time test. The pg_upgrade test script needs a fix. The previous code passed "localhost" to postgres -k, which only happened to work because Windows used to ignore the -k argument value altogether. We instead need to pass an empty string to get the desired effect. The test suites will continue to not use Unix-domain sockets on Windows. This requires a small tweak in pg_regress.c. The TAP tests don't need to be changed because they decide by the operating system rather than HAVE_UNIX_SOCKETS. Reviewed-by: Andrew Dunstan <andrew.dunstan@2ndquadrant.com> Discussion: https://www.postgresql.org/message-id/flat/54bde68c-d134-4eb8-5bd3-8af33b72a010@2ndquadrant.com
2020-03-19pg_upgrade: make get_major_server_version() err msg consistentBruce Momjian
This patch fixes the error message in get_major_server_version() to be "could not parse version file", and uses the full file path name, rather than just the data directory path. Also, commit 4109bb5de4 added the cause of the failure to the "could not open" error message, and improved quoting. This patch backpatches the "could not open" cause to PG 12, where it was first widely used, and backpatches the quoting fix in that patch to all supported releases. Reported-by: Tom Lane Discussion: https://postgr.es/m/87pne2w98h.fsf@wibble.ilmari.org Author: Dagfinn Ilmari Mannsåker Backpatch-through: 9.5
2020-03-18Implement type regcollationPeter Eisentraut
This will be helpful for a following commit and it's also just generally useful, like the other reg* types. Author: Julien Rouhaud Reviewed-by: Thomas Munro and Michael Paquier Discussion: https://postgr.es/m/CAEepm%3D0uEQCpfq_%2BLYFBdArCe4Ot98t1aR4eYiYTe%3DyavQygiQ%40mail.gmail.com
2020-03-04Move pg_upgrade's Windows link() implementation to AC_REPLACE_FUNCSPeter Eisentraut
This way we can make use of it in other components as well, and it fits better with the rest of the build system. Discussion: https://www.postgresql.org/message-id/flat/72fff73f-dc9c-4ef4-83e8-d2e60c98df48%402ndquadrant.com
2020-03-02Update Microsoft documentation linkPeter Eisentraut
Reported-by: Juan José Santamaría Flecha <juanjo.santamaria@gmail.com> Discussion: https://www.postgresql.org/message-id/CAC%2BAXB1EDXiRPmiVfh%2BWX79x5vXJDU17k0GkDjfyPgOWO4Y5og%40mail.gmail.com
2020-02-28Add PostgreSQL home page to --help outputPeter Eisentraut
Per emerging standard in GNU programs and elsewhere. Autoconf already has support for specifying a home page, so we can just that. Reviewed-by: Daniel Gustafsson <daniel@yesql.se> Discussion: https://www.postgresql.org/message-id/flat/8d389c5f-7fb5-8e48-9a4a-68cec44786fa%402ndquadrant.com
2020-02-28Refer to bug report address by symbol rather than hardcodingPeter Eisentraut
Use the PACKAGE_BUGREPORT macro that is created by Autoconf for referring to the bug reporting address rather than hardcoding it everywhere. This makes it easier to change the address and it reduces translation work. Reviewed-by: Daniel Gustafsson <daniel@yesql.se> Discussion: https://www.postgresql.org/message-id/flat/8d389c5f-7fb5-8e48-9a4a-68cec44786fa%402ndquadrant.com
2020-02-26Include error code in message from pg_upgradeMagnus Hagander
In passing, also quote the filename in one message where it wasn't. Author: Dagfinn Ilmari Mannsåker Discussion: https://postgr.es/m/87pne2w98h.fsf@wibble.ilmari.org
2020-02-18Remove duplicated words in commentsMichael Paquier
Author: Daniel Gustafsson Reviewed-by: Vik Fearing Discussion: https://postgr.es/m/EBC3BFEB-664C-4063-81ED-29F1227DB012@yesql.se
2020-02-11Document the pg_upgrade -j/--jobs option as taking an argumentPeter Eisentraut
2020-02-10Revert "pg_upgrade: Fix quoting of some arguments in pg_ctl command"Michael Paquier
This reverts commit d1c0b61. The patch has some downsides that require more attention, as discussed with Noah Misch. Backpatch-through: 9.5
2020-02-10pg_upgrade: Fix quoting of some arguments in pg_ctl commandMichael Paquier
The previous coding forgot to apply shell quoting to the socket directory and the data folder, leading to failures when running pg_upgrade. This refactors the code generating the pg_ctl command starting clusters to use a more correct shell quoting. Failures are easier to trigger in 12 and newer versions by using a value of --socketdir that includes quotes, but it is also possible to cause failures with quotes included in the default socket directory used by pg_upgrade or the data folders of the clusters involved in the upgrade. As 9.4 is going to be EOL'd with the next minor release, nobody is likely going to upgrade to it now so this branch is not included in the set of branches fixed. Author: Michael Paquier Reviewed-by: Álvaro Herrera, Noah Misch Backpatch-through: 9.5
2020-01-30Clean up newlines following left parenthesesAlvaro Herrera
We used to strategically place newlines after some function call left parentheses to make pgindent move the argument list a few chars to the left, so that the whole line would fit under 80 chars. However, pgindent no longer does that, so the newlines just made the code vertically longer for no reason. Remove those newlines, and reflow some of those lines for some extra naturality. Reviewed-by: Michael Paquier, Tom Lane Discussion: https://postgr.es/m/20200129200401.GA6303@alvherre.pgsql
2020-01-29Invent "trusted" extensions, and remove the pg_pltemplate catalog.Tom Lane
This patch creates a new extension property, "trusted". An extension that's marked that way in its control file can be installed by a non-superuser who has the CREATE privilege on the current database, even if the extension contains objects that normally would have to be created by a superuser. The objects within the extension will (by default) be owned by the bootstrap superuser, but the extension itself will be owned by the calling user. This allows replicating the old behavior around trusted procedural languages, without all the special-case logic in CREATE LANGUAGE. We have, however, chosen to loosen the rules slightly: formerly, only a database owner could take advantage of the special case that allowed installation of a trusted language, but now anyone who has CREATE privilege can do so. Having done that, we can delete the pg_pltemplate catalog, moving the knowledge it contained into the extension script files for the various PLs. This ends up being no change at all for the in-core PLs, but it is a large step forward for external PLs: they can now have the same ease of installation as core PLs do. The old "trusted PL" behavior was only available to PLs that had entries in pg_pltemplate, but now any extension can be marked trusted if appropriate. This also removes one of the stumbling blocks for our Python 2 -> 3 migration, since the association of "plpythonu" with Python 2 is no longer hard-wired into pg_pltemplate's initial contents. Exactly where we go from here on that front remains to be settled, but one problem is fixed. Patch by me, reviewed by Peter Eisentraut, Stephen Frost, and others. Discussion: https://postgr.es/m/5889.1566415762@sss.pgh.pa.us
2020-01-01Update copyrights for 2020Bruce Momjian
Backpatch-through: update all files in master, backpatch legal files through 9.4
2019-12-06Improve some comments in pg_upgrade.cMichael Paquier
When restoring database schemas on a new cluster, database "template1" is processed first, followed by all other databases in parallel, including "postgres". Both "postgres" and "template1" have some extra handling to propagate each one's properties, but comments were confusing regarding which one is processed where. Author: Julien Rouhaud Reviewed-by: Daniel Gustafsson Discussion: https://postgr.es/m/CAOBaU_a2iviTG7FE10yO_gcW+zQCHNFhRA_NDiktf3UR65BHdw@mail.gmail.com
2019-11-28Remove useless "return;" linesAlvaro Herrera
Discussion: https://postgr.es/m/20191128144653.GA27883@alvherre.pgsql
2019-11-27pg_upgrade: adjust error paragraph width to be consistentBruce Momjian
Previously these error paragraphs were too wide. Backpatch-through: 13
2019-11-27pg_upgrade: improve instructions for fixing incompatible isn useBruce Momjian
This clarifies instructions on how to dump/reload databases that use incompatible isn versions. Reported-by: Alvaro Herrera Discussion: https://postgr.es/m/20191114190652.GA23586@alvherre.pgsql Reviewed-by: Daniel Gustafsson <daniel@yesql.se> Backpatch-through: 13
2019-11-13Handle arrays and ranges in pg_upgrade's test for non-upgradable types.Tom Lane
pg_upgrade needs to check whether certain non-upgradable data types appear anywhere on-disk in the source cluster. It knew that it has to check for these types being contained inside domains and composite types; but it somehow overlooked that they could be contained in arrays and ranges, too. Extend the existing recursive-containment query to handle those cases. We probably should have noticed this oversight while working on commit 0ccfc2822 and follow-ups, but we failed to :-(. The whole thing's possibly a bit overdesigned, since we don't really expect that any of these types will appear on disk; but if we're going to the effort of doing a recursive search then it's silly not to cover all the possibilities. While at it, refactor so that we have only one copy of the search logic, not three-and-counting. Also, to keep the branches looking more alike, back-patch the output wording change of commit 1634d3615. Back-patch to all supported branches. Discussion: https://postgr.es/m/31473.1573412838@sss.pgh.pa.us
2019-11-05Split all OBJS style lines in makefiles into one-line-per-entry style.Andres Freund
When maintaining or merging patches, one of the most common sources for conflicts are the list of objects in makefiles. Especially when the split across lines has been changed on both sides, which is somewhat common due to attempting to stay below 80 columns, those conflicts are unnecessarily laborious to resolve. By splitting, and alphabetically sorting, OBJS style lines into one object per line, conflicts should be less frequent, and easier to resolve when they still occur. Author: Andres Freund Discussion: https://postgr.es/m/20191029200901.vww4idgcxv74cwes@alap3.anarazel.de
2019-10-30Fix typos in the codeMichael Paquier
Author: Vignesh C Reviewed-by: Dilip Kumar, Michael Paquier Discussion: https://postgr.es/m/CALDaNm0ni+GAOe4+fbXiOxNrVudajMYmhJFtXGX-zBPoN8ixhw@mail.gmail.com
2019-10-25Make the order of the header file includes consistent in non-backend modules.Amit Kapila
Similar to commit 7e735035f2, this commit makes the order of header file inclusion consistent for non-backend modules. In passing, fix the case where we were using angle brackets (<>) for the local module includes instead of quotes (""). Author: Vignesh C Reviewed-by: Amit Kapila Discussion: https://postgr.es/m/CALDaNm2Sznv8RR6Ex-iJO6xAdsxgWhCoETkaYX=+9DW3q0QCfA@mail.gmail.com
2019-10-23pg_upgrade: adjust error output to use new database list formatBruce Momjian
Commit a524f50d0f added old_11_check_for_sql_identifier_data_type_usage(), but it did not use the clearer database error list format added to the master branch in commit 1634d36157. This commit fixes that. Backpatch-through: master
2019-10-16Improve the check for pg_catalog.unknown data type in pg_upgradeTomas Vondra
The pg_upgrade check for pg_catalog.unknown type when upgrading from 9.6 had a couple of issues with domains and composite types - it detected even composite types unused in objects with storage. So for example this was enough to trigger an unnecessary pg_upgrade failure: CREATE TYPE unknown_composite AS (u pg_catalog.unknown) On the other hand, this only happened with composite types directly on the pg_catalog.unknown data type, but not with a domain. So this was not detected CREATE DOMAIN unknown_domain AS pg_catalog.unknown; CREATE TYPE unknown_composite_2 AS (u unknown_domain); unlike the first example. These false positives and inconsistencies are unfortunate, but what's worse we've failed to detected objects using the pg_catalog.unknown type through a domain. So we missed cases like this CREATE TABLE t (u unknown_composite_2); The consequence is clusters broken after a pg_upgrade. This fixes these false positives and false negatives by using the same recursive CTE introduced by eaf900e842 for sql_identifier. Backpatch all the way to 10, where the of pg_catalog.unknown data type was restricted. Author: Tomas Vondra Backpatch-to: 10- Discussion: https://postgr.es/m/16045-673e8fa6b5ace196%40postgresql.org
2019-10-16Improve the check for pg_catalog.line data type in pg_upgradeTomas Vondra
The pg_upgrade check for pg_catalog.line data type when upgrading from 9.3 had a couple of issues with domains and composite types. Firstly, it triggered false positives for composite types unused in objects with storage. This was enough to trigger an unnecessary pg_upgrade failure: CREATE TYPE line_composite AS (l pg_catalog.line) On the other hand, this only happened with composite types directly on the pg_catalog.line data type, but not with a domain. So this was not detected CREATE DOMAIN line_domain AS pg_catalog.line; CREATE TYPE line_composite_2 AS (l line_domain); unlike the first example. These false positives and inconsistencies are unfortunate, but what's worse we've failed to detected objects using the pg_catalog.line data type through a domain. So we missed cases like this CREATE TABLE t (l line_composite_2); The consequence is clusters broken after a pg_upgrade. This fixes these false positives and false negatives by using the same recursive CTE introduced by eaf900e842 for sql_identifier. 9.3 did not support domains on composite types, but we can still have multi-level composite types. Backpatch all the way to 9.4, where the format for pg_catalog.line data type changed. Author: Tomas Vondra Backpatch-to: 9.4- Discussion: https://postgr.es/m/16045-673e8fa6b5ace196%40postgresql.org
2019-10-15Correct reference to pg_catalog.regtype in pg_upgrade queryTomas Vondra
The recursive CTE added in 0ccfc28223 referenced pg_catalog.regtype, without the schema part, unlike all other queries in pg_upgrade. Backpatch-to: 12
2019-10-14Check for tables with sql_identifier during pg_upgradeTomas Vondra
Commit 7c15cef86d changed sql_identifier data type to be based on name instead of varchar. Unfortunately, this breaks on-disk format for this data type. Luckily, that should be a very rare problem, as this data type is used only in information_schema views, so this only affects user objects (tables, materialized views and indexes). One way to end in such situation is to do CTAS with a query on those system views. There are two options to deal with this - we can either abort pg_upgrade if there are user objects with sql_identifier columns in pg_upgrade, or we could replace the sql_identifier type with varchar. Considering how rare the issue is expected to be, and the complexity of replacing the data type (e.g. in matviews), we've decided to go with the simple check. The query is somewhat complex - the sql_identifier data type may be used indirectly - through a domain, a composite type or both, possibly in multiple levels. Detecting this requires a recursive CTE. Backpatch to 12, where the sql_identifier definition changed. Reported-by: Hans Buschmann Author: Tomas Vondra Reviewed-by: Tom Lane Backpatch-to: 12 Discussion: https://postgr.es/m/16045-673e8fa6b5ace196%40postgresql.org
2019-10-10pg_upgrade: Clean up some redundant codePeter Eisentraut
No need to call exit() after pg_fatal(). Clean up a few stragglers for consistency.
2019-10-08pg_upgrade: clarify the database names in error filesBruce Momjian
Previously, the "Database:" label in the error file was unclear if the label was a status report or the problem was _in_ the database. New text is "In database:". Reported-by: Justin Pryzby Discussion: https://postgr.es/m/20191002172337.GC9680@telsasoft.com Backpatch-through: head
2019-09-18pg_upgrade/test.sh: Quote sed(1) argumentAlvaro Herrera
Lack of quotes results in failure to run the test under older Solaris. Author: Marina Polyakova, Victor Wagner Discussion: https://postgr.es/m/feba89f89e8925b3535cb7d72b9e05e1@postgrespro.ru
2019-09-09Prevent msys2 conversion of "cmd /c" switch to a file pathAndrew Dunstan
Modern versions of msys2 have changed the treatment of "cmd /c" so that the runtime will try to convert the switch to a native file path. This patch adds a setting to inhibit that behaviour. Discussion: https://postgr.es/m/3227042f-cfcc-745a-57dd-fb8c471f8ddf@2ndQuadrant.com Backpatch to all live branches.
2019-08-29Error out on too many command-line argumentsPeter Eisentraut
Fix up oid2name, pg_upgrade, and pgbench to error out on too many command-line arguments. This makes it match the behavior of other PostgreSQL programs. Author: Peter Eisentraut, Ibrar Ahmed Discussion: https://www.postgresql.org/message-id/flat/f2554627-04e7-383a-ef01-ab99bb6a291c%402ndquadrant.com
2019-08-27Add missing newline in help output.Tom Lane
Daniel Gustafsson Discussion: https://postgr.es/m/F2FB03F2-B112-4E51-842E-12C50DCA2F4A@yesql.se
2019-08-26Treat MINGW and MSYS the same in pg_upgrade test scriptAndrew Dunstan
On msys2, 'uname -s' reports a string starting MSYS instead on MINGW as happens on msys1. Treat these both the same way. This reverts 608a710195a4b in favor of a more general solution. Backpatch to all live branches.
2019-08-19Fix inconsistencies and typos in the tree, take 11Michael Paquier
This fixes various typos in docs and comments, and removes some orphaned definitions. Author: Alexander Lakhin Discussion: https://postgr.es/m/5da8e325-c665-da95-21e0-c8a99ea61fbf@gmail.com
2019-08-13Fix inconsistencies and typos in the tree, take 10Michael Paquier
This addresses some issues with unnecessary code comments, fixes various typos in docs and comments, and removes some orphaned structures and definitions. Author: Alexander Lakhin Discussion: https://postgr.es/m/9aabc775-5494-b372-8bcb-4dfc0bd37c68@gmail.com
2019-08-09Refactor logic to remove trailing CR/LF characters from stringsMichael Paquier
b654714 has reworked the way trailing CR/LF characters are removed from strings. This commit introduces a new routine in common/string.c and refactors the code so as the logic is in a single place, mostly. Author: Michael Paquier Reviewed-by: Bruce Momjian Discussion: https://postgr.es/m/20190801031820.GF29334@paquier.xyz
generated by cgit v1.2.3 (git 2.46.0) at 2025-10-25 22:41:06 +0000