- 16 Oct, 2019 6 commits
-
-
Tomas Vondra authored
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
-
Andres Freund authored
The test in 93765bd9 added an event trigger to ensure that the tested table rewrites do not get optimized away (as happened in the past). But doing so would require running the tests in isolation, as otherwise the trigger might also fire in concurrent sessions, causing test failures there. Reported-By: Tom Lane Discussion: https://postgr.es/m/3328.1570740683@sss.pgh.pa.us Backpatch: 12, just as 93765bd9
-
Michael Paquier authored
Author: Vignesh C Discussion: https://postgr.es/m/CALDaNm0LPk9vTGTBPBRv0=fX=94o4r6-DuBbHNeCN2AH5bufLw@mail.gmail.com
-
Thomas Munro authored
The previous commit forgot to remove this test, which no longer holds on all systems.
-
Thomas Munro authored
Using glibc's version string to detect potential collation definition changes is not 100% reliable, but it's better than nothing. Currently this affects only collations explicitly provided by "libc". More work will be needed to handle the default collation. Author: Thomas Munro, based on a suggestion from Christoph Berg Reviewed-by: Peter Eisentraut Discussion: https://postgr.es/m/4b76c6d4-ae5e-0dc6-7d0d-b5c796a07e34%402ndquadrant.com
-
Michael Paquier authored
This fixes multiple areas of the documentation: - COPY for its past compatibility section. - SET ROLE mentioning INHERITS instead of INHERIT - PREPARE referring to stmt_name, that is not present. - Extension documentation about format name with upgrade scripts. Backpatch down to 9.4 for the relevant parts. Author: Alexander Lakhin Discussion: https://postgr.es/m/bf95233a-9943-b341-e2ff-a860c28af481@gmail.com Backpatch-through: 9.4
-
- 15 Oct, 2019 1 commit
-
-
Andres Freund authored
Since the introduction of different slot types, in 1a0586de, we create a virtual slot in tuplesort_begin_cluster(). While that looks right, it unfortunately doesn't actually work, as ExecStoreHeapTuple() is used to store tuples in the slot. Unfortunately no regression tests for CLUSTER on expression indexes existed so far. Fix the slot type, and add bare bones tests for CLUSTER on expression indexes. Reported-By: Justin Pryzby Author: Andres Freund Discussion: https://postgr.es/m/20191011210320.GS10470@telsasoft.com Backpatch: 12, like 1a0586de
-
- 14 Oct, 2019 2 commits
-
-
Tomas Vondra authored
The recursive CTE added in 0ccfc282 referenced pg_catalog.regtype, without the schema part, unlike all other queries in pg_upgrade. Backpatch-to: 12
-
Tomas Vondra authored
Commit 7c15cef8 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
-
- 13 Oct, 2019 5 commits
-
-
Michael Paquier authored
1df5875d has changed the way dependencies are dropped for this command with inheritance trees, which impacts sepgsql. This just updates the regression test output to take care of the failures and adapt to the new code. Reported by buildfarm member rhinoceros. Author: Michael Paquier Reviewed-by: Tom Lane Discussion: https://postgr.es/m/20191013101331.GC1434@paquier.xyz Backpatch-through: 12
-
Peter Eisentraut authored
Use https, consistent host name, remove references to ftp. Also update the URLs for CLDR, which has moved from Trac to GitHub.
-
Tom Lane authored
POSIX sigaction(2) can be told to block a set of signals while a signal handler executes. Make use of that instead of manually blocking and unblocking signals in the postmaster's signal handlers. This should save a few cycles, and it also prevents recursive invocation of signal handlers when many signals arrive in close succession. We have seen buildfarm failures that seem to be due to postmaster stack overflow caused by such recursion (exacerbated by a Linux PPC64 kernel bug). This doesn't change anything about the way that it works on Windows. Somebody might consider adjusting port/win32/signal.c to let it work similarly, but I'm not in a position to do that. For the moment, just apply to HEAD. Possibly we should consider back-patching this, but it'd be good to let it age awhile first. Discussion: https://postgr.es/m/14878.1570820201@sss.pgh.pa.us
-
Michael Paquier authored
When dropping a column on a partitioned table which has one or more partitioned indexes, the operation was failing as dependencies with partitioned indexes using the column dropped were not getting removed in a way consistent with the columns involved across all the relations part of an inheritance tree. This commit refactors the code executing column drop so as all the columns from an inheritance tree to remove are gathered first, and dropped all at the end. This way, we let the dependency machinery sort out by itself the deletion of all the columns with the partitioned indexes across a partition tree. This issue has been introduced by 1d92a0c9, so backpatch down to REL_12_STABLE. Author: Amit Langote, Michael Paquier Reviewed-by: Álvaro Herrera, Ashutosh Sharma Discussion: https://postgr.es/m/CA+HiwqE9kuBsZ3b5pob2-cvE8ofzPWs-og+g8bKKGnu6b4-yTQ@mail.gmail.com Backpatch-through: 12
-
- 12 Oct, 2019 2 commits
-
-
Peter Eisentraut authored
Within the context of SCRAM, "verifier" has a specific meaning in the protocol, per RFCs. The existing code used "verifier" differently, to mean whatever is or would be stored in pg_auth.rolpassword. Fix this by using the term "secret" for this, following RFC 5803. Reviewed-by: Michael Paquier <michael@paquier.xyz> Discussion: https://www.postgresql.org/message-id/flat/be397b06-6e4b-ba71-c7fb-54cae84a7e18%402ndquadrant.com
-
Noah Misch authored
With xlc v16.1.0, it causes internal compiler errors. With xlc versions not exhibiting that bug, removing -qsrcmsg merely changes the compiler error reporting format. Back-patch to 9.4 (all supported versions). Discussion: https://postgr.es/m/20191003064105.GA3955242@rfd.leadboat.com
-
- 11 Oct, 2019 1 commit
-
-
Fujii Masao authored
In v11 or before, those settings could not take effect in crash recovery because they are specified in recovery.conf and crash recovery always starts without recovery.conf. But commit 2dedf4d9 integrated recovery.conf into postgresql.conf and which unexpectedly allowed those settings to take effect even in crash recovery. This is definitely not good behavior. To fix the issue, this commit makes crash recovery always ignore restore_command and recovery_end_command settings. Back-patch to v12 where the issue was added. Author: Fujii Masao Reviewed-by: Peter Eisentraut Discussion: https://postgr.es/m/e445616d-023e-a268-8aa1-67b8b335340c@pgmasters.net
-
- 10 Oct, 2019 3 commits
-
-
Tom Lane authored
This reverts commit f7ab8028. Per discussion, we can't remove an exported symbol without a SONAME bump, which we don't want to do. In particular that breaks usage of current libpq.so with pre-9.3 versions of psql etc, which need libpq to export pqsignal(). As noted in that commit message, exporting the symbol from libpgport.a won't work reliably; but actually we don't want to export src/port's implementation anyway. Any pre-9.3 client is going to be expecting the definition that pqsignal() had before 9.3, which was that it didn't set SA_RESTART for SIGALRM. Hence, put back pqsignal() in a separate source file in src/interfaces/libpq, and give it the old semantics. Back-patch to v12. Discussion: https://postgr.es/m/E1g5vmT-0003K1-6S@gemulon.postgresql.org
-
Peter Eisentraut authored
No need to call exit() after pg_fatal(). Clean up a few stragglers for consistency.
-
Andres Freund authored
In c2fe139c I made ATRewriteTable() use tuple slots. Unfortunately I did not notice that columns can be added in a rewrite that do not have a default, when another column is added/altered requiring one. Initialize columns to NULL again, and add tests. Bug: #16038 Reported-By: anonymous Author: Andres Freund Discussion: https://postgr.es/m/16038-5c974541f2bf6749@postgresql.org Backpatch: 12, where the bug was introduced in c2fe139c
-
- 09 Oct, 2019 5 commits
-
-
Peter Eisentraut authored
This reverts commit 9f90b1d0. This needs some refinements in the pg_dump and pg_upgrade tests.
-
Peter Eisentraut authored
Using glibc's version number to detect potential collation definition changes is not 100% reliable, but it's better than nothing. Author: Thomas Munro Reviewed-by: Peter Eisentraut Discussion: https://postgr.es/m/4b76c6d4-ae5e-0dc6-7d0d-b5c796a07e34%402ndquadrant.com
-
Michael Paquier authored
The file descriptor was opened with read-only to fsync a regular file, which would cause EBADFD errors on some platforms. This is similar to the recent fix done by a586cc4b (which was broken by me with 82a5649f), except that I noticed this issue while monitoring the backend code for similar mistakes. Backpatch to 9.4, as this has been introduced since logical decoding exists as of b89e1510. Author: Michael Paquier Reviewed-by: Andres Freund Discussion: https://postgr.es/m/20191006045548.GA14532@paquier.xyz Backpatch-through: 9.4
-
Bruce Momjian authored
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
-
Bruce Momjian authored
Previously, our docs would say "Specifies the number of milliseconds" but it wasn't clear that "milliseconds" was merely the default unit. New text says "Specifies duration (defaults to milliseconds)", which is clearer. Reported-by: basil.bourque@gmail.com Discussion: https://postgr.es/m/15912-2e35e9026f61230b@postgresql.org Backpatch-through: 12
-
- 08 Oct, 2019 4 commits
-
-
Peter Eisentraut authored
As of d9dd406f, we require MSVC 2013, which means _MSC_VER >= 1800. This means that conditionals about older versions of _MSC_VER can be removed or simplified. Previous code was also in some cases handling MinGW, where _MSC_VER is not defined at all, incorrectly, such as in pg_ctl.c and win32_port.h, leading to some compiler warnings. This should now be handled better. Reviewed-by: Michael Paquier <michael@paquier.xyz>
-
Michael Paquier authored
Author: Vignesh C Discussion: https://postgr.es/m/CALDaNm3Dy=dTdx8UCVw=DWbzLzmRUC1dkq45=heOZDUg3U_PtA@mail.gmail.com
-
Michael Paquier authored
Some comments in this file referred to outdated links. This simplifies the outdated comment blocks and refreshes the links. Reported-by: Vignesh C Author: Juan José Santamaría Flecha Discussion: https://postgr.es/m/46C03E17-16F7-4C38-B148-029AC7448E96@gmail.com
-
Michael Paquier authored
This includes new TAP tests for a couple of areas not covered yet and some improvements: - More coverage for --no-ensure-shutdown, the enforced recovery step and --dry-run. - Failures with option combinations and basic option checks. - Removal of a duplicated comment. Author: Alexey Kondratov, Michael Paquier Discussion: https://postgr.es/m/20191007010651.GD14532@paquier.xyz
-
- 07 Oct, 2019 9 commits
-
-
Bruce Momjian authored
The docs for sync and async multimaster replication were unclear about when to use it, and when it has benefits; this change clarifies that. Reported-by: juha-pekka.eloranta@reaktor.fi Discussion: https://postgr.es/m/156856543824.1274.12180817186798859836@wrigleys.postgresql.org Backpatch-through: 9.4
-
Bruce Momjian authored
This should help people clearly know that these days start at midnight. Reported-by: David Harper Discussion: https://postgr.es/m/156258047907.1181.11324468080514061996@wrigleys.postgresql.org Backpatch-through: 9.4
-
Bruce Momjian authored
Previously it was mentioned in the lock_timeout docs in a confusing location. Reported-by: ivaylo.zlatanov@gmail.com Discussion: https://postgr.es/m/157019615723.25307.15449102262106437404@wrigleys.postgresql.org Backpatch-through: 9.4
-
Tom Lane authored
The postmaster's code path for spawning a bgworker neglected to check whether we already have the max number of live child processes. That's a bit hard to hit, since it would necessarily be a transient condition; but if we do, AssignPostmasterChildSlot() fails causing a postmaster crash, as seen in a report from Bhargav Kamineni. To fix, invoke canAcceptConnections() in the bgworker code path, as we do in the other code paths that spawn children. Since we don't want the same pmState tests in this case, add a child-process-type parameter to canAcceptConnections() so that it can know what to do. Back-patch to 9.5. In principle the same hazard exists in 9.4, but the code is enough different that this patch wouldn't quite fix it there. Given the tiny usage of bgworkers in that branch it doesn't seem worth creating a variant patch for it. Discussion: https://postgr.es/m/18733.1570382257@sss.pgh.pa.us
-
Peter Eisentraut authored
Since 63bd0db1 we don't use tzname anymore, so we don't need to check for it. Instead, just keep the part of PGAC_STRUCT_TIMEZONE that we need, which is the check for struct tm.tm_zone. Discussion: https://www.postgresql.org/message-id/flat/5eb11a37-f3ca-5fb7-308f-4485dec25a2e%402ndquadrant.com
-
Peter Eisentraut authored
Change from HAVE_TM_ZONE to HAVE_STRUCT_TM_TM_ZONE.
-
Tom Lane authored
Temporarily change pg_ctl so that the postmaster's exit status will be printed (to the postmaster's stdout). This is to help identify the cause of intermittent "postmaster exited during a parallel transaction" failures seen on a couple of buildfarm members. This change degrades pg_ctl's functionality in a couple of minor ways, so we'll revert it once we've obtained the desired info. Discussion: https://postgr.es/m/18537.1570421268@sss.pgh.pa.us
-
Peter Eisentraut authored
HEAD as used here was CVS terminology. Now we mean master.
-
Michael Paquier authored
This includes a couple of changes around the new behavior of pg_rewind which enforces recovery to happen once on a cluster not shut down cleanly: - Some comments and documentation improvements. - Shutdown the cluster to rewind with immediate mode in all the tests, this allows to check after the forced recovery behavior which is wanted as new default. - Use -F for the forced recovery step, so as postgres does not use fsync. This was useless as a final sync is done once the tool is done. Author: Michael Paquier Reviewed-by: Alexey Kondratov Discussion: https://postgr.es/m/20191004083721.GA1829@paquier.xyz
-
- 06 Oct, 2019 2 commits
-
-
Tom Lane authored
Commit aa087ec6 was a bit over-hasty about the doc changes needed while splitting pg_statistic_ext_data off from pg_statistic_ext. It duplicated one para and inserted another in what seems to me to be the wrong section. Fix that up, and in passing do some minor copy-editing. Per report from noborusai. Discussion: https://postgr.es/m/CAAM3qnLXLUz4mOBkqa8jxigpKhKNxzSuvwpjvCRPvO5EqWjxSg@mail.gmail.com
-
Tom Lane authored
Commit 1cff1b95 included some code that supposed it could repalloc() a memory chunk to a smaller size without risk of the chunk moving. That was not a great idea, because it depended on undocumented behavior of AllocSetRealloc, which commit c477f3e4 changed thereby breaking it. (Not to mention that this code ought to work with other memory context types, which might not work the same...) So get rid of the repalloc calls, and instead just wipe the now-unused ListCell array and/or tell Valgrind it's NOACCESS, as if we'd freed it. In cases where the initial list allocation had been quite large, this could represent an annoying waste of space. In principle we could ameliorate that by allocating the initial cell array separately when it exceeds some threshold. But that would complicate new_list() which is hot code, and the returns would materialize only in narrow cases. On balance I don't think it'd be worth it. Discussion: https://postgr.es/m/17059.1570208426@sss.pgh.pa.us
-