aboutsummaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAge
...
* Use standard compare_exchange loop style in ProcArrayGroupClearXid().Noah Misch2019-10-18
| | | | | | | | Besides style, this might improve performance in the contended case. Reviewed by Amit Kapila. Discussion: https://postgr.es/m/20191015035348.GA4166224@rfd.leadboat.com
* For all ppc compilers, implement compare_exchange and fetch_add with asm.Noah Misch2019-10-18
| | | | | | | | This is more like how we handle s_lock.h and arch-x86.h. Reviewed by Tom Lane. Discussion: https://postgr.es/m/20191005173400.GA3979129@rfd.leadboat.com
* 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
* Remove last traces of heap_open/close in the treeMichael Paquier2019-10-19
| | | | | | | | | | | | | Since pluggable storage has been introduced, those two routines have been replaced by table_open/close, with some compatibility macros still present to allow extensions to compile correctly with v12. Some code paths using the old routines still remained, so replace them. Based on the discussion done, the consensus reached is that it is better to remove those compatibility macros so as nothing new uses the old routines, so remove also the compatibility macros. Discussion: https://postgr.es/m/20191017014706.GF5605@paquier.xyz
* 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
* Refresh some incorrect links in pg_crc.c/hMichael Paquier2019-10-16
| | | | | Author: Vignesh C Discussion: https://postgr.es/m/CALDaNm0LPk9vTGTBPBRv0=fX=94o4r6-DuBbHNeCN2AH5bufLw@mail.gmail.com
* Remove obsolete collation test.Thomas Munro2019-10-16
| | | | | The previous commit forgot to remove this test, which no longer holds on all systems.
* Use libc version as a collation version on glibc systems.Thomas Munro2019-10-16
| | | | | | | | | | | 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
* 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 unicode.org URLsPeter Eisentraut2019-10-13
| | | | | Use https, consistent host name, remove references to ftp. Also update the URLs for CLDR, which has moved from Trac to GitHub.
* In the postmaster, rely on the signal infrastructure to block signals.Tom Lane2019-10-13
| | | | | | | | | | | | | | | | | | | | 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
* Revert "Hack pg_ctl to report postmaster's exit status."Tom Lane2019-10-13
| | | | | This reverts commit 6a5084eed49552bfc8859c438c8d74ad09fc5d3f. We learned what we needed to know from that.
* 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
* Fix use of term "verifier"Peter Eisentraut2019-10-12
| | | | | | | | | | | 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
* 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
* pg_upgrade: Clean up some redundant codePeter Eisentraut2019-10-10
| | | | | No need to call exit() after pg_fatal(). Clean up a few stragglers for consistency.
* 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
* Revert "Use libc version as a collation version on glibc systems."Peter Eisentraut2019-10-09
| | | | | | This reverts commit 9f90b1d08d796a925808b24f77f624a0ff682c77. This needs some refinements in the pg_dump and pg_upgrade tests.
* Use libc version as a collation version on glibc systems.Peter Eisentraut2019-10-09
| | | | | | | | | 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
* 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
* pg_upgrade: clarify the database names in error filesBruce Momjian2019-10-08
| | | | | | | | | | | | 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
* Remove some code for old unsupported versions of MSVCPeter Eisentraut2019-10-08
| | | | | | | | | | | | As of d9dd406fe281d22d5238d3c26a7182543c711e74, 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>
* Update some outdated links about XLC and UNIX specificationMichael Paquier2019-10-08
| | | | | Author: Vignesh C Discussion: https://postgr.es/m/CALDaNm3Dy=dTdx8UCVw=DWbzLzmRUC1dkq45=heOZDUg3U_PtA@mail.gmail.com
* Clarify some comments about ntstatus.h in win32_port.hMichael Paquier2019-10-08
| | | | | | | | | 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
* Improve test coverage of pg_rewindMichael Paquier2019-10-08
| | | | | | | | | | | | 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
* 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
* Simplify PGAC_STRUCT_TIMEZONE Autoconf macroPeter Eisentraut2019-10-07
| | | | | | | | | Since 63bd0db12199c5df043e1dea0f2b574f622b3a4c 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
* Remove use of deprecated Autoconf definePeter Eisentraut2019-10-07
| | | | Change from HAVE_TM_ZONE to HAVE_STRUCT_TM_TM_ZONE.
* Hack pg_ctl to report postmaster's exit status.Tom Lane2019-10-07
| | | | | | | | | | | 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
* Fix incorrect use of term HEAD for GitPeter Eisentraut2019-10-07
| | | | HEAD as used here was CVS terminology. Now we mean master.
* Improve handling and coverage of --no-ensure-shutdown in pg_rewindMichael Paquier2019-10-07
| | | | | | | | | | | | | | | | 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
* Avoid trying to release a List's initial allocation via repalloc().Tom Lane2019-10-06
| | | | | | | | | | | | | | | | | | | | Commit 1cff1b95a 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 c477f3e44 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
* Change MemoryContextMemAllocated to return SizeTomas Vondra2019-10-05
| | | | | | | | Commit f2369bc610 switched most of the memory accounting from int64 to Size, but it forgot to change the MemoryContextMemAllocated return type. So this fixes that omission. Discussion: https://www.postgresql.org/message-id/11238.1570200198%40sss.pgh.pa.us
* 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
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-05 05:42:50 +0000