- 28 May, 2019 7 commits
-
-
Alvaro Herrera authored
I introduced the typo in source code in the course of 75445c15. Repair.
-
Noah Misch authored
When this suite runs installcheck, redirect file creations from src/test/regress to src/bin/pg_upgrade/tmp_check/regress. This closes a race condition in "make -j check-world". If the pg_upgrade suite wrote to a given src/test/regress/results file in parallel with the regular src/test/regress invocation writing it, a test failed spuriously. Even without parallelism, in "make -k check-world", the suite finishing second overwrote the other's regression.diffs. This revealed test "largeobject" assuming @abs_builddir@ is getcwd(), so fix that, too. Buildfarm client REL_10, released fifty-four days ago, supports saving regression.diffs from its new location. When an older client reports a pg_upgradeCheck failure, it will no longer include regression.diffs. Back-patch to 9.5, where pg_upgrade moved to src/bin. Reviewed (in earlier versions) by Andrew Dunstan. Discussion: https://postgr.es/m/20181224034411.GA3224776@rfd.leadboat.com
-
Noah Misch authored
This allows "vcregress upgradecheck" to pass twice in immediate succession, and it's more like how $(prove_check) works. Back-patch to 9.5, where pg_upgrade moved to src/bin. Discussion: https://postgr.es/m/20190520012436.GA1480421@rfd.leadboat.com
-
Andres Freund authored
Mea culpa.
-
Peter Eisentraut authored
This code block was copied/adapted from other similar places but somehow the comment placement was changed so that it makes less sense.
-
Bruce Momjian authored
Reported-by: Gaby Schilders
-
Michael Paquier authored
Author: Gurjeet Singh Discussion: https://postgr.es/m/CABwTF4U_5kEnH93PXZEuEsZHuoSSuBEOqC6pian8vDfLZSQJNA@mail.gmail.com
-
- 27 May, 2019 1 commit
-
-
Peter Eisentraut authored
The old text still had an implicit reference to the virtual behavior, which was not in the final patch. Author: Tobias Bussmann <t.bussmann@gmx.net>
-
- 26 May, 2019 4 commits
-
-
Amit Kapila authored
Reported-by: Alexander Lakhin Author: Alexander Lakhin Reviewed-by: Amit Kapila and Tom Lane Discussion: https://postgr.es/m/7208de98-add8-8537-91c0-f8b089e2928c@gmail.com
-
Peter Eisentraut authored
Change extension for Graphviz files from .dot to .gv. The latter appears to be the generally preferred one nowadays. Discussion: https://www.postgresql.org/message-id/flat/71fe76d2-c7d7-2acc-6762-bbf9e61c566e%402ndquadrant.com
- 25 May, 2019 1 commit
-
-
Amit Kapila authored
Reported-by: Euler Taveira Author: Euler Taveira Discussion: https://postgr.es/m/CAHE3wgjiA8DdnUzH9WqBLxdrUVvjDkKNdHx-MkEg9uV+HtpMfg@mail.gmail.com
-
- 24 May, 2019 3 commits
-
-
Tom Lane authored
Per bug #15819 from Koizumi Satoru. Discussion: https://postgr.es/m/15819-e6191bef1f7334c0@postgresql.org
-
Thomas Munro authored
Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/CA%2BhUKGJFWXmtYo6Frd77RR8YXCHz7hJ2mRy5aHV%3D7fJOqDnBHA%40mail.gmail.com
-
Thomas Munro authored
Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/CA%2BhUKGJFWXmtYo6Frd77RR8YXCHz7hJ2mRy5aHV%3D7fJOqDnBHA%40mail.gmail.com
-
- 23 May, 2019 6 commits
-
-
Andres Freund authored
Some of the wrapper functions didn't match the callback names. Many of them due to staying "consistent" with historic naming of the wrapped functionality. We decided that for most cases it's more important to be for tableam to be consistent going forward, than with the past. The one exception is beginscan/endscan/... because it'd have looked odd to have systable_beginscan/endscan/... with a different naming scheme, and changing the systable_* APIs would have caused way too much churn (including breaking a lot of external users). Author: Ashwin Agrawal, with some small additions by Andres Freund Reviewed-By: Andres Freund Discussion: https://postgr.es/m/CALfoeiugyrXZfX7n0ORCa4L-m834dzmaE8eFdbNR6PMpetU4Ww@mail.gmail.com
-
Michael Paquier authored
The access method name "amname" can be dumped as of 3b925e90, but queries for backends older than 9.5 forgot to map it to a dummy NULL value, causing the column to not be mapped to a number. As a result, pg_dump was throwing some spurious errors in its stderr output coming from libpq: pg_dump: column number -1 is out of range 0..36 Fix this issue by adding a mapping of "amname" to NULL to all the older queries. Discussion: https://postgr.es/m/20190522083038.GA16837@paquier.xyz Author: Michael Paquier Reviewed-by: Dmitry Dolgov, Andres Freund, Tom Lane
-
Andres Freund authored
On master (after 700538) the old version's installed psql was used - even when the old version might not actually be installed / might be installed into a temporary directory. As commonly the case when just executing make check for pg_upgrade, as $oldbindir is just the current version's $bindir. In the back branches, with --install specified, psql from the new version's temporary installation was used, without --install (e.g for NO_TEMP_INSTALL, cf 47b3c266), the new version's installed psql was used (which might or might not exist). Author: Andres Freund Discussion: https://postgr.es/m/20190522175150.c26f4jkqytahajdg@alap3.anarazel.de
-
Andrew Gierth authored
When there were duplicate columns in the hash key list, the array sizes could be miscomputed, resulting in access off the end of the array. Adjust the computation to ensure the array is always large enough. (I considered whether the duplicates could be removed in planning, but I can't rule out the possibility that duplicate columns might have different hash functions assigned. Simpler to just make sure it works at execution time regardless.) Bug apparently introduced in fc4b3dea as part of narrowing down the tuples stored in the hashtable. Reported by Colm McHugh of Salesforce, though I didn't use their patch. Backpatch back to version 10 where the bug was introduced. Discussion: https://postgr.es/m/CAFeeJoKKu0u+A_A9R9316djW-YW3-+Gtgvy3ju655qRHR3jtdA@mail.gmail.com
-
Michael Paquier authored
This uses a method similar to 68a7c24f and now b8c6014a (applied for database creation), which guarantees that GRANT commands using the WITH GRANT OPTION are dumped in a way so as cascading dependencies are respected. Note that tablespaces do not have support for initial privileges via pg_init_privs, so the same method needs to be applied again. It would be nice to merge all the logic generating ACL queries in dumps under the same banner, but this requires extending the support of pg_init_privs to objects that cannot use it yet, so this is left as future work. Discussion: https://postgr.es/m/20190522071555.GB1278@paquier.xyz Author: Michael Paquier Reviewed-by: Nathan Bossart Backpatch-through: 9.6
-
Michael Paquier authored
This has been forgotten in 578b2297, which has removed support for WITH OIDS. Discussion: https://postgr.es/m/CALAY4q99FcFCoG6ddke0V-AksGe82L_+bhDWgEfgZBakB840zA@mail.gmail.com Author: Surafel Temesgen
-
- 22 May, 2019 13 commits
-
-
Tom Lane authored
Make all the perl code look nice, too (for some value of "nice").
-
Tom Lane authored
Switch to 2.1 version of pg_bsd_indent. This formats multiline function declarations "correctly", that is with additional lines of parameter declarations indented to match where the first line's left parenthesis is. Discussion: https://postgr.es/m/CAEepm=0P3FeTXRcU5B2W3jv3PgRVZ-kGUXLGfd42FFhUROO3ug@mail.gmail.com
-
Tom Lane authored
This is still using the 2.0 version of pg_bsd_indent. I thought it would be good to commit this separately, so as to document the differences between 2.0 and 2.1 behavior. Discussion: https://postgr.es/m/16296.1558103386@sss.pgh.pa.us
-
Peter Eisentraut authored
This code was still using the old style of forming a heap tuple rather than using tuple slots. This would be less efficient if a non-heap access method was used. And using tuple slots is actually quite a bit faster when using heap as well. Also add some test cases for generated columns with null values and with varlena values. This lack of coverage was discovered while working on this patch. Discussion: https://www.postgresql.org/message-id/flat/20190331025744.ugbsyks7czfcoksd%40alap3.anarazel.de
-
Fujii Masao authored
Commit 41b54ba7 allowed not only VACUUM but also ANALYZE options to take a boolean argument. But it forgot to update the documentation for ANALYZE. This commit adds the descriptions about those ANALYZE boolean options into the documentation. This patch also updates tab-completion for ANALYZE boolean options. Reported-by: Kyotaro Horiguchi Author: Fujii Masao Reviewed-by: Masahiko Sawada, Michael Paquier Discussion: https://postgr.es/m/CAHGQGwHTUt-kuwgiwe8f0AvTnB+ySqJWh95jvmh-qcoKW9YA9g@mail.gmail.com
-
Tom Lane authored
The original coding of this view relied on a correlated IN sub-query. Our planner is not very bright about correlated sub-queries, and even if it were, there's no way for it to know that the output of pg_get_publication_tables() is duplicate-free, making the de-duplicating semantics of IN unnecessary. Hence, rewrite as a LATERAL sub-query. This provides circa 100X speedup for me with a few hundred published tables (the whole regression database), and things would degrade as roughly O(published_relations * all_relations) beyond that. Because the rules.out expected output changes, force a catversion bump. Ordinarily we might not want to do that post-beta1; but we already know we'll be doing a catversion bump before beta2 to fix pg_statistic_ext issues, so it's pretty much free to fix it now instead of waiting for v13. Per report and fix suggestion from PegoraroF10. Discussion: https://postgr.es/m/1551385426763-0.post@n3.nabble.com
-
Bruce Momjian authored
Move support function mention to the proper section, and reword. Reported-by: Tom Lane Discussion: https://postgr.es/m/5121.1558472431@sss.pgh.pa.us
-
Bruce Momjian authored
Clarify new restriction on recovery_target* variables. Reported-by: Gaby Schilders Discussion: reported via chat
-
Tom Lane authored
That leads to unsatisfied external references if the C compiler fails to elide unused static functions. Apparently, we have no buildfarm members building HEAD that have that issue ... but such compilers still exist in the wild. Need to do something about that. In passing, fix Berkeley-era typo in comment. Discussion: https://postgr.es/m/27054.1558533367@sss.pgh.pa.us
-
Michael Paquier authored
This uses a method similar to 68a7c24f, which guarantees that GRANT commands using the WITH GRANT OPTION are dumped in a way so as cascading dependencies are respected. As databases do not have support for initial privileges via pg_init_privs, we need to repeat again the same ACL reordering method. ACL for databases have been moved from pg_dumpall to pg_dump in v11, so this impacts pg_dump for v11 and above, and pg_dumpall for v9.6 and v10. Discussion: https://postgr.es/m/15788-4e18847520ebcc75@postgresql.org Author: Nathan Bossart Reviewed-by: Haribabu Kommi Backpatch-through: 9.6
-
Michael Meskes authored
Besides implementing the new statement this change fix some issues with the parsing of PREPARE and EXECUTE statements. The different forms of these statements are now all handled in a ujnified way. Author: Matsumura-san <matsumura.ryo@jp.fujitsu.com>
-
- 21 May, 2019 5 commits
-
-
Andres Freund authored
When $(MAKE) is present in a rule, make assumes that target is a submake, and it doesn't need to buffer its output. But in this case it's a shell script that needs buffered output. Avoid that heuristic, by referring to $(MAKE) via an indirection. Discussion: https://postgr.es/m/20190521004717.qsktdsugj3shagco@alap3.anarazel.de
-
Andres Freund authored
For pg_upgrade's test we (unless prevented by the caller via via NO_TEMP_INSTALL) built a separate installation. That causes an unnecessary slowdown after the infrastructure introduced by dcae5fac (and unnecessarily duplicates code). Author: Andres Freund Reviewed-By: Tom Lane Discussion: https://postgr.es/m/20190521191918.z7kwnrlj45mk2k67@alap3.anarazel.de https://postgr.es/m/20190521195209.qfzwfxvymguuwlu5@alap3.anarazel.de
-
Bruce Momjian authored
Discussion: https://postgr.es/m/22793.1558399695@sss.pgh.pa.us
-
Bruce Momjian authored
Discussion: https://postgr.es/m/15486.1558393010@sss.pgh.pa.us
-
Bruce Momjian authored
Discussion: https://postgr.es/m/87y330d8ty.fsf@news-spur.riddles.org.uk
-