aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAge
...
* Doc: improve documentation of configuration settings that have units.Tom Lane2019-10-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we added the GUC units feature, we didn't make any great effort to adjust the documentation of individual GUCs; they tended to still say things like "this is the number of milliseconds that ...", even though users might prefer to write some other units, and SHOW might even show the value in other units. Commit 6c9fb69f2 made an effort to improve this situation, but I thought it made things less readable by injecting units information in mid-sentence. It also wasn't very consistent, and did not touch all the GUCs that have units. To improve matters, standardize on the phrasing "If this value is specified without units, it is taken as <units>". Also, try to standardize where this is mentioned, right before the specification of the default. (In a couple of places, doing that would've required more rewriting than seemed justified, so I wasn't 100% consistent about that.) I also tried to use the phrases "amount of time", "amount of memory", etc rather than describing the contents of GUCs in other ways, as those were the majority usage in places that weren't overcommitting to a particular unit. (I left "length of time" alone in a couple of places, though.) I failed to resist the temptation to copy-edit some awkward text, too. Backpatch to v12, like 6c9fb69f2, mainly because v12 hasn't diverged much from HEAD yet. Discussion: https://postgr.es/m/15882.1571942223@sss.pgh.pa.us
* Avoid failure when selecting a namespace node in XMLTABLE.Tom Lane2019-10-25
| | | | | | | | | | | | | | | It appears that libxml2 doesn't bother to set the "children" field of an XML_NAMESPACE_DECL node to null; that field just contains garbage. In v10 and v11, this can result in a crash in XMLTABLE(). The rewrite done in commit 251cf2e27 fixed this, somewhat accidentally, in v12. We're not going to back-patch 251cf2e27, however. The case apparently doesn't have wide use, so rather than risk introducing other problems, just add a safety check to throw an error. Even though no bug manifests in v12/HEAD, add the relevant test case there too, to prevent future regressions. Chapman Flack (per private report)
* Get rid of useless/dangerous redefinition of bool in ECPG.Tom Lane2019-10-25
| | | | | | | | | | | | | | | | | | | | | | | | | pgtypeslib_extern.h contained fallback definitions of "bool", "FALSE", and "TRUE". The latter two are just plain unused, and have been for awhile. The former came into play only if there wasn't a macro definition of "bool", which is true only if we aren't using <stdbool.h>. However, it then defined bool as "char"; since commit d26a810eb that conflicts with c.h's desire to use "unsigned char". We'd missed seeing any bad effects of that due to accidental header inclusion order choices, but dddf4cdc3 exposed that it was problematic. To fix, let's just get rid of these definitions. They should not be needed because everyplace in Postgres should be relying on c.h to provide a definition for type bool. (Note that despite its name, pgtypeslib_extern.h isn't exposed to any outside code; we don't install it.) This doesn't fully resolve the issue, because ecpglib.h is doing similar things, but that seems to require more thought to fix. Back-patch to v12 where d26a810eb came in, to forestall any unpleasant surprises from future back-patched bug fixes. Discussion: https://postgr.es/m/CAA4eK1LmaKO7Du9M9Lo=kxGU8sB6aL8fa3sF6z6d5yYYVe3BuQ@mail.gmail.com
* Handle interrupts within a transaction context in REINDEX CONCURRENTLYMichael Paquier2019-10-25
| | | | | | | | | | | | | | | | | | | | | | | Phases 2 (building the new index) and 3 (validating the new index) checked for interrupts outside a transaction context, having as consequence to not release session-level locks taken on the parent relation and the old and new indexes processed. This could for example be triggered with statement_timeout and a bad timing, and would issue confusing error messages when shutting down the session still holding the locks (note that an assertion failure would be triggered first), on top of more issues with concurrent sessions trying to take a lock that would interfere with the SHARE UPDATE EXCLUSIVE locks hold here. This moves all the interruption checks inside a transaction context. Note that I have manually tested all interruptions to make sure that invalid indexes can be cleaned up properly. Partition indexes still have issues on their own with some missing dependency handling, which will be dealt with in a follow-up patch. Reported-by: Justin Pryzby Author: Michael Paquier Discussion: https://postgr.es/m/20191013025145.GC4475@telsasoft.com Backpatch-through: 12
* docs: fix wording of REFRESH CONCURRENTLY manual pageBruce Momjian2019-10-23
| | | | | | | | Reported-by: Asim / apraveen@pivotal.io Discussion: https://postgr.es/m/157076828181.26165.15231292023740913543@wrigleys.postgresql.org Backpatch-through: 9.4
* Acquire properly session-level lock on new index in REINDEX CONCURRENTLYMichael Paquier2019-10-23
| | | | | | | | | | | | | | | In the first transaction run for REINDEX CONCURRENTLY, a thinko in the existing logic caused two session locks to be taken on the old index, causing the session lock on the newly-created index to be missed. This made possible concurrent DDL commands (like ALTER INDEX) on the new index while REINDEX CONCURRENTLY was processing from the point where the first internal transaction committed. This issue has been discovered while digging into another bug. Author: Michael Paquier Discussion: https://postgr.es/m/20191021074323.GB1869@paquier.xyz Backpatch-through: 12
* Fix thinkos from 4f4061b for libpq integer parsingMichael Paquier2019-10-23
| | | | | | | | | | | A check was redundant. While on it, add an assertion to make sure that the parsing routine is never called with a NULL input. All the code paths currently calling the parsing routine are careful with NULL inputs already, but future callers may forget that. Reported-by: Peter Eisentraut, Lars Kanis Discussion: https://postgr.es/m/ec64956b-4597-56b6-c3db-457d15250fe4@2ndquadrant.com Backpatch-through: 12
* Clean up properly error_context_stack in autovacuum worker on exceptionMichael Paquier2019-10-23
| | | | | | | | | | | | | | Any callback set would have no meaning in the context of an exception. As an autovacuum worker exits quickly in this context, this could be only an issue within EmitErrorReport(), where the elog hook is for example called. That's unlikely to going to be a problem, but let's be clean and consistent with other code paths handling exceptions. This is present since 2909419, which introduced autovacuum. Author: Ashwin Agrawal Reviewed-by: Tom Lane, Michael Paquier Discussion: https://postgr.es/m/CALfoeisM+_+dgmAdAOHAu0k-ZpEHHqSSG=GRf3pKJGm8OqWX0w@mail.gmail.com Backpatch-through: 9.4
* Deal with yet another issue related to "Norwegian (Bokmål)" locale.Tom Lane2019-10-21
| | | | | | | | | | | | | It emerges that recent versions of Windows (at least 2016 Standard) spell this locale name as "Norwegian Bokmål_Norway.1252", defeating our mapping code that translates "Norwegian (Bokmål)_Norway" to something that's all-ASCII (cf commits db29620d4 and aa1d2fc5e). Add another mapping entry to handle this spelling. Per bug #16068 from Robert Ford. Like the previous patches, back-patch to all supported branches. Discussion: https://postgr.es/m/16068-4cb6eeaa7eb46d93@postgresql.org
* Use CFLAGS_SL while probing linkability of libperl.Tom Lane2019-10-21
| | | | | | | | | | | | | | | | On recent Red Hat platforms (at least RHEL 8 and Fedora 30, maybe older), configure's probe for libperl failed if the user forces CFLAGS to be -O0. This is because some code in perl's inline.h fails to be optimized away at -O0, and said code doesn't work if compiled without -fPIC. To fix, add CFLAGS_SL to the compile flags used during the libperl probe. This is a better simulation of the way that plperl is built, anyway, so it might forestall other issues in future. Per gripe from Kyotaro Horiguchi. Back-patch to all supported branches, since people might want to build older branches on these platforms. Discussion: https://postgr.es/m/20191010.144533.263180400.horikyota.ntt@gmail.com
* Select CFLAGS_SL at configure time, not in platform-specific Makefiles.Tom Lane2019-10-21
| | | | | | | | | | | | | | | | | | | | | | | Move the platform-dependent logic that sets CFLAGS_SL from src/makefiles/Makefile.foo to src/template/foo, so that the value is determined at configure time and thus is available while running configure's tests. On a couple of platforms this might save a few microseconds of build time by eliminating a test that make otherwise has to do over and over. Otherwise it's pretty much a wash for build purposes; in particular, this makes no difference to anyone who might be overriding CFLAGS_SL via a make option. This patch in itself does nothing with the value and thus should not change any behavior, though you'll probably have to re-run configure to get a correctly updated Makefile.global. We'll use the new configure variable in a follow-on patch. Per gripe from Kyotaro Horiguchi. Back-patch to all supported branches, because the follow-on patch is a portability bug fix. Discussion: https://postgr.es/m/20191010.144533.263180400.horikyota.ntt@gmail.com
* Update obsolete comment.Etsuro Fujita2019-10-21
| | | | | | | | | | | Commit b52b7dc25, which moved code creating PartitionBoundInfo in RelationBuildPartitionDesc() in partcache.c (relocated to partdesc.c afterwards) to partbounds.c, should have updated this, but didn't. Author: Etsuro Fujita Reviewed-by: Alvaro Herrera Backpatch-through: 12 Discussion: https://postgr.es/m/CAPmGK16Uxr%3DPatiGyaRwiQVLB7Y-GqbkK3AxRLVYzU0Czv%3DsEw%40mail.gmail.com
* Fix memory leak introduced in commit 7df159a620.Amit Kapila2019-10-21
| | | | | | | | | | | | | We memorize all internal and empty leaf pages in the 1st vacuum stage for gist indexes. They are used in the 2nd stage, to delete all the empty pages. There was a memory context page_set_context for this purpose, but we never used it. Reported-by: Amit Kapila Author: Dilip Kumar Reviewed-by: Amit Kapila Backpatch-through: 12, where it got introduced Discussion: https://postgr.es/m/CAA4eK1LGr+MN0xHZpJ2dfS8QNQ1a_aROKowZB+MPNep8FVtwAA@mail.gmail.com
* Fix error reporting of connect_timeout in libpq for value parsingMichael Paquier2019-10-21
| | | | | | | | | | | The logic was correctly detecting a parsing failure, but the parsing error did not get reported back to the client properly. Reported-by: Ed Morley Author: Lars Kanis Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/a9b4cbd7-4ecb-06b2-ebd7-1739bbff3217@greiz-reinsdorf.de Backpatch-through: 12
* Fix parsing of integer values for connection parameters in libpqMichael Paquier2019-10-21
| | | | | | | | | | | | | | | | Commit e7a2217 has introduced stricter checks for integer values in connection parameters for libpq. However this failed to correctly check after trailing whitespaces, while leading whitespaces were discarded per the use of strtol(3). This fixes and refactors the parsing logic to handle both cases consistently. Note that trying to restrict the use of trailing whitespaces can easily break connection strings like in ECPG regression tests (these have allowed me to catch the parsing bug with connect_timeout). Author: Michael Paquier Reviewed-by: Lars Kanis Discussion: https://postgr.es/m/a9b4cbd7-4ecb-06b2-ebd7-1739bbff3217@greiz-reinsdorf.de Backpatch-through: 12
* For PowerPC instruction "addi", use constraint "b".Noah Misch2019-10-18
| | | | | | | | | | | | Without "b", a variant of the tas() code miscompiles on macOS 10.4. This may also fix a compilation failure involving macOS 10.1. Today's compilers have been allocating acceptable registers with or without this change, but this future-proofs the code by precisely conveying the acceptable registers. Back-patch to 9.4 (all supported versions). Reviewed by Tom Lane. Discussion: https://postgr.es/m/20191009063900.GA4066266@rfd.leadboat.com
* Fix failure of archive recovery with recovery_min_apply_delay enabled.Fujii Masao2019-10-18
| | | | | | | | | | | | | | | | | | | | | | | | recovery_min_apply_delay parameter is intended for use with streaming replication deployments. However, the document clearly explains that the parameter will be honored in all cases if it's specified. So it should take effect even if in archive recovery. But, previously, archive recovery with recovery_min_apply_delay enabled always failed, and caused assertion failure if --enable-caasert is enabled. The cause of this problem is that; the ownership of recoveryWakeupLatch that recovery_min_apply_delay uses was taken only when standby mode is requested. So unowned latch could be used in archive recovery, and which caused the failure. This commit changes recovery code so that the ownership of recoveryWakeupLatch is taken even in archive recovery. Which prevents archive recovery with recovery_min_apply_delay from failing. Back-patch to v9.4 where recovery_min_apply_delay was added. Author: Fujii Masao Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/CAHGQGwEyD6HdZLfdWc+95g=VQFPR4zQL4n+yHxQgGEGjaSVheQ@mail.gmail.com
* Make crash recovery ignore recovery_min_apply_delay setting.Fujii Masao2019-10-18
| | | | | | | | | | | | | | | | | | | In v11 or before, this setting could not take effect in crash recovery because it's specified in recovery.conf and crash recovery always starts without recovery.conf. But commit 2dedf4d9a8 integrated recovery.conf into postgresql.conf and which unexpectedly allowed this setting to take effect even in crash recovery. This is definitely not good behavior. To fix the issue, this commit makes crash recovery always ignore recovery_min_apply_delay setting. Back-patch to v12 where the issue was added. Author: Fujii Masao Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/CAHGQGwEyD6HdZLfdWc+95g=VQFPR4zQL4n+yHxQgGEGjaSVheQ@mail.gmail.com Discussion: https://postgr.es/m/e445616d-023e-a268-8aa1-67b8b335340c@pgmasters.net
* Fix typoAlvaro Herrera2019-10-18
| | | | | | | Apparently while this code was being developed, ReindexRelationConcurrently operated on multiple relations. The version that was ultimately pushed doesn't, so this comment's use of plural is inaccurate.
* Update comments about progress reporting by index_dropAlvaro Herrera2019-10-18
| | | | | | | | Michaël Paquier complained that index_drop is requesting progress reporting for non-obvious reasons, so let's add a comment to explain why. Discussion: https://postgr.es/m/20191017010412.GH2602@paquier.xyz
* Fix timeout handling in logical replication workerMichael Paquier2019-10-18
| | | | | | | | | | | | | | | | The timestamp tracking the last moment a message is received in a logical replication worker was initialized in each loop checking if a message was received or not, causing wal_receiver_timeout to be ignored in basically any logical replication deployments. This also broke the ping sent to the server when reaching half of wal_receiver_timeout. This simply moves the initialization of the timestamp out of the apply loop to the beginning of LogicalRepApplyLoop(). Reported-by: Jehan-Guillaume De Rorthais Author: Julien Rouhaud Discussion: https://postgr.es/m/CAOBaU_ZHESFcWva8jLjtZdCLspMj7vqaB2k++rjHLY897ZxbYw@mail.gmail.com Backpatch-through: 10
* Fix minor bug in logical-replication walsender shutdownAlvaro Herrera2019-10-17
| | | | | | | | | | | | | | | | | Logical walsender should exit when it catches up with sending WAL during shutdown; but there was a rare corner case when it failed to because of a race condition that puts it back to wait for more WAL instead -- but since there wasn't any, it'd not shut down immediately. It would only continue the shutdown when wal_sender_timeout terminates the sleep, which causes annoying waits during shutdown procedure. Restructure the code so that we no longer forget to set WalSndCaughtUp in that case. This was an oversight in commit c6c333436. Backpatch all the way down to 9.4. Author: Craig Ringer, Álvaro Herrera Discussion: https://postgr.es/m/CAMsr+YEuz4XwZX_QmnX_-2530XhyAmnK=zCmicEnq1vLr0aZ-g@mail.gmail.com
* Fix parallel restore of FKs to partitioned tablesAlvaro Herrera2019-10-17
| | | | | | | | | | | | | | | When an FK constraint is created, it needs the index on the referenced table to exist and be valid. When doing parallel pg_restore and the referenced table was partitioned, this condition can sometimes not be met, because pg_dump didn't emit sufficient object dependencies to ensure so; this means that parallel pg_restore would fail in certain conditions. Fix by having pg_dump make the FK constraint object dependent on the partition attachment objects for the constraint's referenced index. This has been broken since f56f8f8da6af, so backpatch to Postgres 12. Discussion: https://postgr.es/m/20191005224333.GA9738@alvherre.pgsql
* When restoring GUCs in parallel workers, show an error context.Thomas Munro2019-10-17
| | | | | | | | | | | Otherwise it can be hard to see where an error is coming from, when the parallel worker sets all the GUCs that it received from the leader. Bug #15726. Back-patch to 9.5, where RestoreGUCState() appeared. Reported-by: Tiago Anastacio Reviewed-by: Daniel Gustafsson, Tom Lane Discussion: https://postgr.es/m/15726-6d67e4fa14f027b3%40postgresql.org
* Fix bug that could try to freeze running multixacts.Thomas Munro2019-10-17
| | | | | | | | | | | | | Commits 801c2dc7 and 801c2dc7 made it possible for vacuum to try to freeze a multixact that is still running. That was prevented by a check, but raised an error. Repair. Back-patch all the way. Author: Nathan Bossart, Jeremy Schneider Reported-by: Jeremy Schneider Reviewed-by: Jim Nasby, Thomas Munro Discussion: https://postgr.es/m/DAFB8AFF-2F05-4E33-AD7F-FF8B0F760C17%40amazon.com
* Fix crash when reporting CREATE INDEX progressAlvaro Herrera2019-10-16
| | | | | | | | | | | | A race condition can make us try to dereference a NULL pointer to the PGPROC struct of a process that's already finished. That results in crashes during REINDEX CONCURRENTLY and CREATE INDEX CONCURRENTLY. This was introduced in ab0dfc961b6a, so backpatch to pg12. Reported by: Justin Pryzby Reviewed-by: Michaël Paquier Discussion: https://postgr.es/m/20191012004446.GT10470@telsasoft.com
* Improve the check for pg_catalog.unknown data type in pg_upgradeTomas Vondra2019-10-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Improve the check for pg_catalog.line data type in pg_upgradeTomas Vondra2019-10-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Replace alter_table.sql test usage of event triggers.Andres Freund2019-10-16
| | | | | | | | | | | | The test in 93765bd956b 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 93765bd956b
* Doc: Fix incorrect contributor name in release notesMichael Paquier2019-10-16
| | | | | | | A typo from commit 27b4121 is at the origin of the mistake. Author: Alexander Lakhin Discussion: https://postgr.es/m/bf95233a-9943-b341-e2ff-a860c28af481@gmail.com
* Doc: Fix various inconsistenciesMichael Paquier2019-10-16
| | | | | | | | | | | | | | 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
* Fix CLUSTER on expression indexes.Andres Freund2019-10-15
| | | | | | | | | | | | | | | | Since the introduction of different slot types, in 1a0586de3657, 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 1a0586de3657
* Correct reference to pg_catalog.regtype in pg_upgrade queryTomas Vondra2019-10-15
| | | | | | | The recursive CTE added in 0ccfc28223 referenced pg_catalog.regtype, without the schema part, unlike all other queries in pg_upgrade. Backpatch-to: 12
* Check for tables with sql_identifier during pg_upgradeTomas Vondra2019-10-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Update test output of sepgsql for ALTER TABLE COLUMN DROPMichael Paquier2019-10-14
| | | | | | | | | | | | | | 1df5875 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
* Fix dependency handling of column drop with partitioned tablesMichael Paquier2019-10-13
| | | | | | | | | | | | | | | | | | | | | | 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 1d92a0c, 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
* AIX: Stop adding option -qsrcmsg.Noah Misch2019-10-12
| | | | | | | | 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
* Make crash recovery ignore restore_command and recovery_end_command settings.Fujii Masao2019-10-11
| | | | | | | | | | | | | | | | | | 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 2dedf4d9a8 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
* Put back pqsignal() as an exported libpq symbol.Tom Lane2019-10-10
| | | | | | | | | | | | | | | | | | This reverts commit f7ab80285. 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
* Fix table rewrites that include a column without a default.Andres Freund2019-10-09
| | | | | | | | | | | | | | In c2fe139c201c 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 c2fe139c201c
* Flush logical mapping files with fd opened for read/write at checkpointMichael Paquier2019-10-09
| | | | | | | | | | | | | | | 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 82a5649), 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 b89e151. Author: Michael Paquier Reviewed-by: Andres Freund Discussion: https://postgr.es/m/20191006045548.GA14532@paquier.xyz Backpatch-through: 9.4
* doc: improve docs so config value default units are clearerBruce Momjian2019-10-08
| | | | | | | | | | | | | 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
* docs: Improve A?synchronous Multimaster Replication descr.Bruce Momjian2019-10-07
| | | | | | | | | | | 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
* docs: clarify that today/tomorrow/yesterday is at 00:00Bruce Momjian2019-10-07
| | | | | | | | | | 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
* doc: move mention of log_min_error_statement in a better spotBruce Momjian2019-10-07
| | | | | | | | | | | 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
* Check for too many postmaster children before spawning a bgworker.Tom Lane2019-10-07
| | | | | | | | | | | | | | | | | | | | 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
* Doc: improve docs about pg_statistic_ext_data.Tom Lane2019-10-06
| | | | | | | | | | | | Commit aa087ec64 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
* Report test_atomic_ops() failures consistently, via macros.Noah Misch2019-10-05
| | | | | | | | | | This prints the unexpected value in more failure cases, and it removes forty-eight hand-maintained error messages. Back-patch to 9.5, which introduced these tests. Reviewed (in an earlier version) by Andres Freund. Discussion: https://postgr.es/m/20190915160021.GA24376@alvherre.pgsql
* Avoid use of wildcard in pg_waldump's .gitignore.Tom Lane2019-10-05
| | | | | | | | | | | | | | | This would be all right, maybe, if it didn't also match a file that definitely should not be ignored. We don't add rmgrs so often that manual maintenance of this file list is impractical, so just write out the list. (I find the equivalent wildcard use in the Makefile pretty lazy and unsafe as well, but will leave that alone until it actually causes a problem.) Per bug #16042 from Denis Stuchalin. Discussion: https://postgr.es/m/16042-c174ee692ac21cbd@postgresql.org
* Disable one more set of tests from c8841199509.Andres Freund2019-10-05
| | | | | Discussion: https://postgr.es/m/20191004222437.45qmglpto43pd3jb@alap3.anarazel.de Backpatch: 9.6-, just like c8841199509 and 6e61d75f525
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-06 16:19:25 +0000