aboutsummaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAge
...
* 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
* 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
* Disable one set of tests from c8841199509.Andres Freund2019-10-04
| | | | | | | | | | | One of the upsert related tests is unstable (sometimes even hanging until isolationtester's step timeout is reached). Based on preliminary analysis that might be a problem outside of just that test, but not really related to EPQ and triggers. Disable for now, to get the buildfarm greener again. Discussion: https://postgr.es/m/20191004222437.45qmglpto43pd3jb@alap3.anarazel.de Backpatch: 9.6-, just like c8841199509.
* Add isolation tests for the combination of EPQ and triggers.Andres Freund2019-10-04
| | | | | | | | | | | | | | | | As evidenced by bug #16036 this area is woefully under-tested. Add fairly extensive tests for the combination. Backpatch back to 9.6 - before that isolationtester was not capable enough. While we don't backpatch tests all the time, future fixes to trigger.c would potentially look different enough in 12+ from the earlier branches that introducing bugs during backpatching is more likely than normal. Also, it's just a crucial and undertested area of the code. Author: Andres Freund Discussion: https://postgr.es/m/16036-28184c90d952fb7f@postgresql.org Backpatch: 9.6-, the earliest these tests work
* Fix crash caused by EPQ happening with a before update trigger present.Andres Freund2019-10-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When ExecBRUpdateTriggers()'s GetTupleForTrigger() follows an EPQ chain the former needs to run the result tuple through the junkfilter again, and update the slot containing the new version of the tuple to contain that new version. The input tuple may already be in the junkfilter's output slot, which used to be OK - we don't need the previous version anymore. Unfortunately ff11e7f4b9ae started to use ExecCopySlot() to update newslot, and ExecCopySlot() doesn't support copying a slot into itself, leading to a slot in a corrupt state, which then can cause crashes or other symptoms. Fix this by skipping the ExecCopySlot() when copying into itself. While we could have easily made ExecCopySlot() handle that case, it seems better to add an assert forbidding doing so instead. As the goal of copying might be to make the contents of one slot independent from another, it seems failure prone to handle doing so silently. A follow-up commit will add tests for the obviously under-covered combination of EPQ and triggers. Done as a separate commit as it might make sense to backpatch them further than this bug. Also remove confusion with confusing variable names for slots in ExecBRDeleteTriggers() and ExecBRUpdateTriggers(). Bug: #16036 Reported-By: Антон Власов Author: Andres Freund Discussion: https://postgr.es/m/16036-28184c90d952fb7f@postgresql.org Backpatch: 12-, where ff11e7f4b9ae was merged
* Use a fd opened for read/write when syncing slots during startup, take 2.Andres Freund2019-10-04
| | | | | | | | | | | | | | | | | | | | | | | Cribbing from dfbaed45975: Some operating systems, including the reporter's windows, return EBADFD or similar when fsync() is invoked on a O_RDONLY file descriptor. Unfortunately RestoreSlotFromDisk() does exactly that; which causes failures after restarts in at least some scenarios. If you hit the bug the error message will be something like ERROR: could not fsync file "pg_replslot/$name/state": Bad file descriptor Simply use O_RDWR instead of O_RDONLY when opening the relevant file descriptor to fix the bug. Unfortunately this fix was undone in 82a5649fb9db. Re-apply, and add a comment. Bug: 16039 Reported-By: Hans Buschmann Author: Andres Freund Discussion: https://postgr.es/m/16039-196fc97cc05e141c@postgresql.org Backpatch: 12-, as 82a5649fb9db
* Handle spaces in OpenSSL install location for MSVCAndrew Dunstan2019-10-04
| | | | | | | | | First, make sure that the .exe name is quoted when trying to get the version number. Also, don't quote the lib name for using in the project files if it's already been quoted. This second change applies to all libraries, not just OpenSSL. This has clearly been broken forever, so backpatch to all live branches.
* Rename some toasting functions based on whether they are heap-specific.Robert Haas2019-10-04
| | | | | | | | | | | | | | | | | | | | | | The old names for the attribute-detoasting functions names included the word "heap," which seems outdated now that the heap is only one of potentially many table access methods. On the other hand, toast_insert_or_update and toast_delete are heap-specific, so rename them by adding "heap_" as a prefix. Not all of the work of making the TOAST system fully accessible to AMs other than the heap is done yet, but there seems to be little harm in getting this renaming out of the way now. Commit 8b94dab06617ef80a0901ab103ebd8754427ef5a already divided up the functions among various files partially according to whether it was intended that they should be heap-specific or AM-agnostic, so this is just clarifying the division contemplated by that commit. Patch by me, reviewed and tested by Prabhat Sabu, Thomas Munro, Andres Freund, and Álvaro Herrera. Discussion: http://postgr.es/m/CA+TgmoZv-=2iWM4jcw5ZhJeL18HF96+W1yJeYrnGMYdkFFnEpQ@mail.gmail.com
* Fix bitshiftright()'s zero-padding some more.Tom Lane2019-10-04
| | | | | | | | | | | | | | | Commit 5ac0d9360 failed to entirely fix bitshiftright's habit of leaving one-bits in the pad space that should be all zeroes, because in a moment of sheer brain fade I'd concluded that only the code path used for not-a-multiple-of-8 shift distances needed to be fixed. Of course, a multiple-of-8 shift distance can also cause the problem, so we need to forcibly zero the extra bits in both cases. Per bug #16037 from Alexander Lakhin. As before, back-patch to all supported branches. Discussion: https://postgr.es/m/16037-1d1ebca564db54f4@postgresql.org
* Use Size instead of int64 to track allocated memoryTomas Vondra2019-10-04
| | | | | | | | | | | | | | | | | | | | | Commit 5dd7fc1519 added block-level memory accounting, but used int64 variable to track the amount of allocated memory. That is incorrect, because we have Size for exactly these purposes, but it was mostly harmless until c477f3e449 which changed how we handle with repalloc() when downsizing the chunk. Previously we've ignored these cases and just kept using the original chunk, but now we need to update the accounting, and the code was doing this: context->mem_allocated += blksize - oldblksize; Both blksize and oldblksize are Size (so unsigned) which means the subtraction underflows, producing a very high positive value. On 64-bit platforms (where Size has the same size as mem_alllocated) this happens to work because the result wraps to the right value, but on (some) 32-bit platforms this fails. This fixes two things - it changes mem_allocated (and related variables) to Size, and it splits the update to two separate steps, to prevent any underflows. Discussion: https://www.postgresql.org/message-id/15151.1570163761%40sss.pgh.pa.us
* Remove AtSubStart_Notify.Robert Haas2019-10-04
| | | | | | | | | | Allocate notify-related state lazily instead. This makes trivial subtransactions noticeably faster. Patch by me, reviewed and tested by Dilip Kumar, Kyotaro Horiguchi, and Jeevan Ladhe. Discussion: https://postgr.es/m/CA+TgmobE1J22S1eC-6N-je9LgrcwZypkwp+zH6JXo9mc=4Nk3A@mail.gmail.com
* Fix issues in pg_rewind with --no-ensure-shutdown/--write-recovery-confMichael Paquier2019-10-04
| | | | | | | | | | | This fixes two issues with recent features added in pg_rewind: - --dry-run should do nothing on the target directory, but 927474c forgot to consider that for --write-recovery-conf. - --no-ensure-shutdown was not actually working. There is no test coverage for this option yet, but a subsequent patch will add that. Author: Alexey Kondratov Discussion: https://postgr.es/m/7ca88204-3e0b-2f4c-c8af-acadc4b266e5@postgrespro.ru
* Fix --dry-run mode of pg_rewindMichael Paquier2019-10-04
| | | | | | | | | | | Even if --dry-run mode was specified, the control file was getting updated, preventing follow-up runs of pg_rewind to work properly on the target data folder. The origin of the problem came from the refactoring done by ce6afc6. Author: Alexey Kondratov Discussion: https://postgr.es/m/7ca88204-3e0b-2f4c-c8af-acadc4b266e5@postgrespro.ru Backpatch-through: 12
* Avoid unnecessary out-of-memory errors during encoding conversion.Tom Lane2019-10-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Encoding conversion uses the very simplistic rule that the output can't be more than 4X longer than the input, and palloc's a buffer of that size. This results in failure to convert any string longer than 1/4 GB, which is becoming an annoying limitation. As a band-aid to improve matters, allow the allocated output buffer size to exceed 1GB. We still insist that the final result fit into MaxAllocSize (1GB), though. Perhaps it'd be safe to relax that restriction, but it'd require close analysis of all callers, which is daunting (not least because external modules might call these functions). For the moment, this should allow a 2X to 4X improvement in the longest string we can convert, which is a useful gain in return for quite a simple patch. Also, once we have successfully converted a long string, repalloc the output down to the actual string length, returning the excess to the malloc pool. This seems worth doing since we can usually expect to give back several MB if we take this path at all. This still leaves much to be desired, most notably that the assumption that MAX_CONVERSION_GROWTH == 4 is very fragile, and yet we have no guard code verifying that the output buffer isn't overrun. Fixing that would require significant changes in the encoding conversion APIs, so it'll have to wait for some other day. The present patch seems safely back-patchable, so patch all supported branches. Alvaro Herrera and Tom Lane Discussion: https://postgr.es/m/20190816181418.GA898@alvherre.pgsql Discussion: https://postgr.es/m/3614.1569359690@sss.pgh.pa.us
* Allow repalloc() to give back space when a large chunk is downsized.Tom Lane2019-10-03
| | | | | | | | | | | | | | | | | | Up to now, if you resized a large (>8K) palloc chunk down to a smaller size, aset.c made no attempt to return any space to the malloc pool. That's unpleasant if a really large allocation is resized to a significantly smaller size. I think no such cases existed when this code was designed, and I'm not sure whether they're common even yet, but an upcoming fix to encoding conversion will certainly create such cases. Therefore, fix AllocSetRealloc so that it gives realloc() a chance to do something with the block. This doesn't noticeably increase complexity, we mostly just have to change the order in which the cases are considered. Back-patch to all supported branches. Discussion: https://postgr.es/m/20190816181418.GA898@alvherre.pgsql Discussion: https://postgr.es/m/3614.1569359690@sss.pgh.pa.us
* Selectively include window frames in expression walks/mutates.Andrew Gierth2019-10-03
| | | | | | | | | | | | | | | | | | | | query_tree_walker and query_tree_mutator were skipping the windowClause of the query, without regard for the fact that the startOffset and endOffset in a WindowClause node are expression trees that need to be processed. This was an oversight in commit ec4be2ee6 from 2010 which added the expression fields; the main symptom is that function parameters in window frame clauses don't work in inlined functions. Fix (as conservatively as possible since this needs to not break existing out-of-tree callers) and add tests. Backpatch all the way, since this has been broken since 9.0. Per report from Alastair McKinley; fix by me with kibitzing and review from Tom Lane. Discussion: https://postgr.es/m/DB6PR0202MB2904E7FDDA9D81504D1E8C68E3800@DB6PR0202MB2904.eurprd02.prod.outlook.com
* pgbench: add --partitions and --partition-method options.Amit Kapila2019-10-03
| | | | | | | | | | | | | These new options allow users to partition the pgbench_accounts table by specifying the number of partitions and partitioning method. The values allowed for partitioning method are range and hash. This feature allows users to measure the overhead of partitioning if any. Author: Fabien COELHO Reviewed-by: Amit Kapila, Amit Langote, Dilip Kumar, Asif Rehman, and Alvaro Herrera Discussion: https://postgr.es/m/alpine.DEB.2.21.1907230826190.7008@lancre
* Remove temporary WAL and history files at the end of archive recoveryMichael Paquier2019-10-02
| | | | | | | | | | | | | | | cbc55da has reworked the order of some actions at the end of archive recovery. Unfortunately this overlooked the fact that the startup process needs to remove RECOVERYXLOG (for temporary WAL segment newly recovered from archives) and RECOVERYHISTORY (for temporary history file) at this step, leaving the files around even after recovery ended. Backpatch to 9.5, like the previous commit. Author: Sawada Masahiko Reviewed-by: Fujii Masao, Michael Paquier Discussion: https://postgr.es/m/CAD21AoBO_eDQub6zojFnWtnmutRBWvYf7=cW4Hsqj+U_R26w3Q@mail.gmail.com Backpatch-through: 9.5
* Revert hooks for session start and end, take twoMichael Paquier2019-10-02
| | | | | | | | | | | The location of the session end hook has been chosen so as it is possible to allow modules to do their own transactions, however any trying to any any subsystem which went through before_shmem_exit() would cause issues, limiting the pluggability of the hook. Per discussion with Tom Lane and Andres Freund. Discussion: https://postgr.es/m/18722.1569906636@sss.pgh.pa.us
* Blind attempt to fix pglz_maximum_compressed_sizeTomas Vondra2019-10-01
| | | | | | | | Commit 11a078cf87 triggered failures on big-endian machines, and the only plausible place for an issue seems to be that TOAST_COMPRESS_SIZE calls VARSIZE instead of VARSIZE_ANY. So try fixing that blindly. Discussion: https://www.postgresql.org/message-id/20191001131803.j6uin7nho7t6vxzy%40development
* Mark two variables in in aset.c with PG_USED_FOR_ASSERTS_ONLYTomas Vondra2019-10-01
| | | | | This fixes two compiler warnings about unused variables in non-assert builds, introduced by 5dd7fc1519461548eebf26c33eac6878ea3e8788.
* Optimize partial TOAST decompressionTomas Vondra2019-10-01
| | | | | | | | | | | | | | | | | | | | | | | Commit 4d0e994eed added support for partial TOAST decompression, so the decompression is interrupted after producing the requested prefix. For prefix and slices near the beginning of the entry, this may saves a lot of decompression work. That however only deals with decompression - the whole compressed entry was still fetched and re-assembled, even though the compression used only a small fraction of it. This commit improves that by computing how much compressed data may be needed to decompress the requested prefix, and then fetches only the necessary part. We always need to fetch a bit more compressed data than the requested (uncompressed) prefix, because the prefix may not be compressible at all and pglz itself adds a bit of overhead. That means this optimization is most effective when the requested prefix is much smaller than the whole compressed entry. Author: Binguo Bao Reviewed-by: Andrey Borodin, Tomas Vondra, Paul Ramsey Discussion: https://www.postgresql.org/message-id/flat/CAL-OGkthU9Gs7TZchf5OWaL-Gsi=hXqufTxKv9qpNG73d5na_g@mail.gmail.com
* Fix test_session_hooks with parallel workersMichael Paquier2019-10-01
| | | | | | | | | | | | | Several buildfarm machines have been complaining about the new module test_session_hooks to be unstable, like crake and thorntail. The issue was that the module was trying to log some start and end session activity for parallel workers, which makes little sense as they don't support DML, so just prevent this pattern to happen in the module. This could be reproduced by enforcing force_parallel_mode=regress, which is the value used by some of the buildfarm members. Discussion: https://postgr.es/m/20191001045246.GF2781@paquier.xyz
* Add hooks for session start and session end, take twoMichael Paquier2019-10-01
| | | | | | | | | | | | | | | | These hooks can be used in loadable modules. A simple test module is included. The first attempt was done with cd8ce3a but we lacked handling for NO_INSTALLCHECK in the MSVC scripts (problem solved afterwards by 431f1599) so the buildfarm got angry. This also fixes a couple of issues noticed upon review compared to the first attempt, so the code has slightly changed, resulting in a more simple test module. Author: Fabrízio de Royes Mello, Yugo Nagata Reviewed-by: Andrew Dunstan, Michael Paquier, Aleksandr Parfenov Discussion: https://postgr.es/m/20170720204733.40f2b7eb.nagata@sraoss.co.jp Discussion: https://postgr.es/m/20190823042602.GB5275@paquier.xyz
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-03 05:41:31 +0000