aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAge
...
* Fix assorted memory leaks.Tom Lane2015-07-12
| | | | | | | | Per Coverity (not that any of these are so non-obvious that they should not have been caught before commit). The extent of leakage is probably minor to unnoticeable, but a leak is a leak. Back-patch as necessary. Michael Paquier
* Improve documentation about array concat operator vs. underlying functions.Tom Lane2015-07-09
| | | | | | | | | | | | | The documentation implied that there was seldom any reason to use the array_append, array_prepend, and array_cat functions directly. But that's not really true, because they can help make it clear which case is meant, which the || operator can't do since it's overloaded to represent all three cases. Add some discussion and examples illustrating the potentially confusing behavior that can ensue if the parser misinterprets what was meant. Per a complaint from Michael Herold. Back-patch to 9.2, which is where || started to behave this way.
* Fix postmaster's handling of a startup-process crash.Tom Lane2015-07-09
| | | | | | | | | | | | | | | | | | | | | | | Ordinarily, a failure (unexpected exit status) of the startup subprocess should be considered fatal, so the postmaster should just close up shop and quit. However, if we sent the startup process a SIGQUIT or SIGKILL signal, the failure is hardly "unexpected", and we should attempt restart; this is necessary for recovery from ordinary backend crashes in hot-standby scenarios. I attempted to implement the latter rule with a two-line patch in commit 442231d7f71764b8c628044e7ce2225f9aa43b67, but it now emerges that that patch was a few bricks shy of a load: it failed to distinguish the case of a signaled startup process from the case where the new startup process crashes before reaching database consistency. That resulted in infinitely respawning a new startup process only to have it crash again. To handle this properly, we really must track whether we have sent the *current* startup process a kill signal. Rather than add yet another ad-hoc boolean to the postmaster's state, I chose to unify this with the existing RecoveryError flag into an enum tracking the startup process's state. That seems more consistent with the postmaster's general state machine design. Back-patch to 9.0, like the previous patch.
* Fix another broken link in documentation.Heikki Linnakangas2015-07-09
| | | | | | | | Tom fixed another one of these in commit 7f32dbcd, but there was another almost identical one in libpq docs. Per his comment: HP's web server has apparently become case-sensitive sometime recently. Per bug #13479 from Daniel Abraham. Corrected link identified by Alvaro.
* Replace use of "diff -q".Noah Misch2015-07-08
| | | | | | | POSIX does not specify the -q option, and many implementations do not offer it. Don't bother changing the MSVC build system, because having non-GNU diff on Windows is vanishingly unlikely. Back-patch to 9.2, where this invocation was introduced.
* Fix null pointer dereference in "\c" psql command.Noah Misch2015-07-08
| | | | | | The psql crash happened when no current connection existed. (The second new check is optional given today's undocumented NULL argument handling in PQhost() etc.) Back-patch to 9.0 (all supported versions).
* Fix portability issue in pg_upgrade test script: avoid $PWD.Tom Lane2015-07-07
| | | | | | | | | | | | | | | | | SUSv2-era shells don't set the PWD variable, though anything more modern does. In the buildfarm environment this could lead to test.sh executing with PWD pointing to $HOME or another high-level directory, so that there were conflicts between concurrent executions of the test in different branch subdirectories. This appears to be the explanation for recent intermittent failures on buildfarm members binturong and dingo (and might well have something to do with the buildfarm script's failure to capture log files from pg_upgrade tests, too). To fix, just use `pwd` in place of $PWD. AFAICS test.sh is the only place in our source tree that depended on $PWD. Back-patch to all versions containing this script. Per buildfarm. Thanks to Oskari Saarenmaa for diagnosing the problem.
* Improve handling of out-of-memory in libpq.Heikki Linnakangas2015-07-07
| | | | | | | | | | | | If an allocation fails in the main message handling loop, pqParseInput3 or pqParseInput2, it should not be treated as "not enough data available yet". Otherwise libpq will wait indefinitely for more data to arrive from the server, and gets stuck forever. This isn't a complete fix - getParamDescriptions and getCopyStart still have the same issue, but it's a step in the right direction. Michael Paquier and me. Backpatch to all supported versions.
* Turn install.bat into a pure one line wrapper fort he perl script.Heikki Linnakangas2015-07-07
| | | | | | | | | | | | | Build.bat and vcregress.bat got similar treatment years ago. I'm not sure why install.bat wasn't treated at the same time, but it seems like a good idea anyway. The immediate problem with the old install.bat was that it had quoting issues, and wouldn't work if the target directory's name contained spaces. This fixes that problem. I committed this to master yesterday, this is a backpatch of the same for all supported versions.
* Fix logical decoding bug leading to inefficient reopening of files.Andres Freund2015-07-07
| | | | | | | | | | | | | | | | | | | | When spilling transaction data to disk a simple typo caused the output file to be closed and reopened for every serialized change. That happens to not have a huge impact on linux, which is why it probably wasn't noticed so far, but on windows that appears to trigger actual disk writes after every change. Not fun. The bug fortunately does not have any impact besides speed. A change could end up being in the wrong segment (last instead of next), but since we read all files to the end, that's just ugly, not really problematic. It's not a problem to upgrade, since transaction spill files do not persist across restarts. Bug: #13484 Reported-By: Olivier Gosseaume Discussion: 20150703090217.1190.63940@wrigleys.postgresql.org Backpatch to 9.4, where logical decoding was added.
* Fix pg_recvlogical not to fsync output when it's a tty or pipe.Andres Freund2015-07-07
| | | | | | | | | | | | The previous coding tried to handle possible failures when fsyncing a tty or pipe fd by accepting EINVAL - but apparently some platforms (windows, OSX) don't reliably return that. So instead check whether the output fd refers to a pipe or a tty when opening it. Reported-By: Olivier Gosseaume, Marko Tiikkaja Discussion: 559AF98B.3050901@joh.to Backpatch to 9.4, where pg_recvlogical was added.
* Remove incorrect warning from pg_archivecleanup document.Fujii Masao2015-07-06
| | | | | | | | | | The .backup file name can be passed to pg_archivecleanup even if it includes the extension which is specified in -x option. However, previously the document incorrectly warned a user not to do that. Back-patch to 9.2 where pg_archivecleanup's -x option and the warning were added.
* Fix some typos in regression test comments.Tom Lane2015-07-05
| | | | | | Back-patch to avoid unnecessary cross-branch differences. CharSyam
* Make numeric form of PG version number readily available in Makefiles.Tom Lane2015-07-05
| | | | | | | | | | | | | | | | Expose PG_VERSION_NUM (e.g., "90600") as a Make variable; but for consistency with the other Make variables holding similar info, call the variable just VERSION_NUM not PG_VERSION_NUM. There was some discussion of making this value available as a pg_config value as well. However, that would entail substantially more work than this two-line patch. Given that there was not exactly universal consensus that we need this at all, let's just do a minimal amount of work for now. Back-patch of commit a5d489ccb7e613c7ca3be6141092b8c1d2c13fa7, so that this variable is actually useful for its intended purpose sometime before 2020. Michael Paquier, reviewed by Pavel Stehule
* PL/Perl: Add alternative expected file for Perl 5.22Peter Eisentraut2015-07-03
|
* Fix pgbench progress report behaviour when pgbench or a query gets stuck.Heikki Linnakangas2015-07-03
| | | | | | | | | | | | | There were two issues here. First, if a query got stuck so that it took e.g. 5 seconds, and progress interval was 1 second, no progress reports were printed until the query returned. Fix so that we wake up specifically to print the progress report. Secondly, if pgbench got stuck so that it would nevertheless not print a progress report on time, and enough time passes that it's already time to print the next progress report, just skip the one that was missed. Before this patch, it would print the missed one with 0 TPS immediately after the previous one. Fabien Coelho. Backpatch to 9.4, where progress reports were added.
* Don't emit a spurious space at end of line in pg_dump of event triggers.Heikki Linnakangas2015-07-02
| | | | Backpatch to 9.3 and above, where event triggers were added.
* Fix broken link in documentation.Tom Lane2015-06-30
| | | | | HP's web server has apparently become case-sensitive sometime recently. Per bug #13479 from Daniel Abraham. Corrected link identified by Alvaro.
* Test -lrt for sched_yieldAlvaro Herrera2015-06-30
| | | | | | Apparently, this is needed in some Solaris versions. Author: Oskari Saarenmaa
* Don't call PageGetSpecialPointer() on page until it's been initialized.Heikki Linnakangas2015-06-30
| | | | | | | | | | After calling XLogInitBufferForRedo(), the page might be all-zeros if it was not in page cache already. btree_xlog_unlink_page initialized the page correctly, but it called PageGetSpecialPointer before initializing it, which would lead to a corrupt page at WAL replay, if the unlinked page is not in page cache. Backpatch to 9.4, the bug came with the rewrite of B-tree page deletion.
* Back-patch some minor bug fixes in GUC code.Tom Lane2015-06-28
| | | | | | | | | | | | | | | In 9.4, fix a 9.4.1 regression that allowed multiple entries for a PGC_POSTMASTER variable to cause bogus complaints in the postmaster log. (The issue here was that commit bf007a27acd7b2fb unintentionally reverted 3e3f65973a3c94a6, which suppressed any duplicate entries within ParseConfigFp. Back-patch the reimplementation just made in HEAD, which makes use of an "ignore" field to prevent application of superseded items.) Add missed failure check in AlterSystemSetConfigFile(). We don't really expect ParseConfigFp() to fail, but that's not an excuse for not checking. In both 9.3 and 9.4, remove mistaken assignment to ConfigFileLineno that caused line counting after an include_dir directive to be completely wrong.
* Fix comment for GetCurrentIntegerTimestamp().Kevin Grittner2015-06-28
| | | | | | The unit of measure is microseconds, not milliseconds. Backpatch to 9.3 where the function and its comment were added.
* Fix function declaration style to respect the coding standard.Tatsuo Ishii2015-06-28
|
* Fix test_decoding's handling of nonexistant columns in old tuple versions.Andres Freund2015-06-27
| | | | | | | | | | | | | | | test_decoding used fastgetattr() to extract column values. That's wrong when decoding updates and deletes if a table's replica identity is set to FULL and new columns have been added since the old version of the tuple was created. Due to the lack of a crosscheck with the datum's natts values an invalid value will be output, leading to errors or worse. Bug: #13470 Reported-By: Krzysztof Kotlarski Discussion: 20150626100333.3874.90852@wrigleys.postgresql.org Backpatch to 9.4, where the feature, including the bug, was added.
* Add opaque declaration of HTAB to tqual.h.Kevin Grittner2015-06-27
| | | | | | | | | | | | | Commit b89e151054a05f0f6d356ca52e3b725dd0505e53 added the ResolveCminCmaxDuringDecoding declaration to tqual.h, which uses an HTAB parameter, without declaring HTAB. It accidentally fails to fail to build with current sources because a declaration happens to be included, directly or indirectly, in all source files that currently use tqual.h before tqual.h is first included, but we shouldn't count on that. Since an opaque declaration is enough here, just use that, as was done in snapmgr.h. Backpatch to 9.4, where the HTAB reference was added to tqual.h.
* Revoke incorrectly applied patch versionSimon Riggs2015-06-27
|
* Avoid hot standby cancels from VAC FREEZESimon Riggs2015-06-27
| | | | | | | | | | | | VACUUM FREEZE generated false cancelations of standby queries on an otherwise idle master. Caused by an off-by-one error on cutoff_xid which goes back to original commit. Backpatch to all versions 9.0+ Analysis and report by Marco Nenciarini Bug fix by Simon Riggs
* Fix a couple of bugs with wal_log_hints.Heikki Linnakangas2015-06-26
| | | | | | | | | | | | | | 1. Replay of the WAL record for setting a bit in the visibility map contained an assertion that a full-page image of that record type can only occur with checksums enabled. But it can also happen with wal_log_hints, so remove the assertion. Unlike checksums, wal_log_hints can be changed on the fly, so it would be complicated to figure out if it was enabled at the time that the WAL record was generated. 2. wal_log_hints has the same effect on the locking needed to read the LSN of a page as data checksums. BufferGetLSNAtomic() didn't get the memo. Backpatch to 9.4, where wal_log_hints was added.
* Allow background workers to connect to no particular database.Robert Haas2015-06-25
| | | | | | | The documentation claims that this is supported, but it didn't actually work. Fix that. Reported by Pavel Stehule; patch by me.
* Fix the logic for putting relations into the relcache init file.Tom Lane2015-06-25
| | | | | | | | | | | | | | | | | | | | | | | | | | Commit f3b5565dd4e59576be4c772da364704863e6a835 was a couple of bricks shy of a load; specifically, it missed putting pg_trigger_tgrelid_tgname_index into the relcache init file, because that index is not used by any syscache. However, we have historically nailed that index into cache for performance reasons. The upshot was that load_relcache_init_file always decided that the init file was busted and silently ignored it, resulting in a significant hit to backend startup speed. To fix, reinstantiate RelationIdIsInInitFile() as a wrapper around RelationSupportsSysCache(), which can know about additional relations that should be in the init file despite being unknown to syscache.c. Also install some guards against future mistakes of this type: make write_relcache_init_file Assert that all nailed relations get written to the init file, and make load_relcache_init_file emit a WARNING if it takes the "wrong number of nailed relations" exit path. Now that we remove the init files during postmaster startup, that case should never occur in the field, even if we are starting a minor-version update that added or removed rels from the nailed set. So the warning shouldn't ever be seen by end users, but it will show up in the regression tests if somebody breaks this logic. Back-patch to all supported branches, like the previous commit.
* Docs: fix claim that to_char('FM') removes trailing zeroes.Tom Lane2015-06-25
| | | | | | Of course, what it removes is leading zeroes. Seems to have been a thinko in commit ffe92d15d53625d5ae0c23f4e1984ed43614a33d. Noted by Hubert Depesz Lubaczewski.
* Improve inheritance_planner()'s performance for large inheritance sets.Tom Lane2015-06-22
| | | | | | | | | | | | | | | | | Commit c03ad5602f529787968fa3201b35c119bbc6d782 introduced a planner performance regression for UPDATE/DELETE on large inheritance sets. It required copying the append_rel_list (which is of size proportional to the number of inherited tables) once for each inherited table, thus resulting in O(N^2) time and memory consumption. While it's difficult to avoid that in general, the extra work only has to be done for append_rel_list entries that actually reference subquery RTEs, which inheritance-set entries will not. So we can buy back essentially all of the loss in cases without subqueries in FROM; and even for those, the added work is mainly proportional to the number of UNION ALL subqueries. Back-patch to 9.2, like the previous commit. Tom Lane and Dean Rasheed, per a complaint from Thomas Munro.
* Truncate strings in tarCreateHeader() with strlcpy(), not sprintf().Noah Misch2015-06-21
| | | | | | | | | | This supplements the GNU libc bug #6530 workarounds introduced in commit 54cd4f04576833abc394e131288bf3dd7dcf4806. On affected systems, a tar-format pg_basebackup failed when some filename beneath the data directory was not valid character data in the postmaster/walsender locale. Back-patch to 9.1, where pg_basebackup was introduced. Extant, bug-prone conversion specifications receive only ASCII bytes or involve low-importance messages.
* Improve multixact emergency autovacuum logic.Andres Freund2015-06-21
| | | | | | | | | | | | | | | | | | | | | | | | | Previously autovacuum was not necessarily triggered if space in the members slru got tight. The first problem was that the signalling was tied to values in the offsets slru, but members can advance much faster. Thats especially a problem if old sessions had been around that previously prevented the multixact horizon to increase. Secondly the skipping logic doesn't work if the database was restarted after autovacuum was triggered - that knowledge is not preserved across restart. This is especially a problem because it's a common panic-reaction to restart the database if it gets slow to anti-wraparound vacuums. Fix the first problem by separating the logic for members from offsets. Trigger autovacuum whenever a multixact crosses a segment boundary, as the current member offset increases in irregular values, so we can't use a simple modulo logic as for offsets. Add a stopgap for the second problem, by signalling autovacuum whenver ERRORing out because of boundaries. Discussion: 20150608163707.GD20772@alap3.anarazel.de Backpatch into 9.3, where it became more likely that multixacts wrap around.
* Add missing check for wal_debug GUC.Andres Freund2015-06-21
| | | | | | | | | | 9a20a9b2 added a new elog(), enabled when WAL_DEBUG is defined. The other WAL_DEBUG dependant messages check for the wal_debug GUC, but this one did not. While at it replace 'upto' with 'up to'. Discussion: 20150610110253.GF3832@alap3.anarazel.de Backpatch to 9.4, the first release containing 9a20a9b2.
* Fix failure to copy setlocale() return value.Noah Misch2015-06-20
| | | | | | | | | | | | | | | | | | | | | | | | | | POSIX permits setlocale() calls to invalidate any previous setlocale() return values, but commit 5f538ad004aa00cf0881f179f0cde789aad4f47e neglected to account for setlocale(LC_CTYPE, NULL) doing so. The effect was to set the LC_CTYPE environment variable to an unintended value. pg_perm_setlocale() sets this variable to assist PL/Perl; without it, Perl would undo PostgreSQL's locale settings. The known-affected configurations are 32-bit, release builds using Visual Studio 2012 or Visual Studio 2013. Visual Studio 2010 is unaffected, as were all buildfarm-attested configurations. In principle, this bug could leave the wrong LC_CTYPE in effect after PL/Perl use, which could in turn facilitate problems like corrupt tsvector datums. No known platform experiences that consequence, because PL/Perl on Windows does not use this environment variable. The bug has been user-visible, as early postmaster failure, on systems with Windows ANSI code page set to CP936 for "Chinese (Simplified, PRC)" and probably on systems using other multibyte code pages. (SetEnvironmentVariable() rejects values containing character data not valid under the Windows ANSI code page.) Back-patch to 9.4, where the faulty commit first appeared. Reported by Didi Hu and 林鹏程. Reviewed by Tom Lane, though this fix strategy was not his first choice.
* Fix thinko in comment (launcher -> worker)Alvaro Herrera2015-06-20
|
* In immediate shutdown, postmaster should not exit till children are gone.Tom Lane2015-06-19
| | | | | | | | | | | | | | | | | | | | This adjusts commit 82233ce7ea42d6ba519aaec63008aff49da6c7af so that the postmaster does not exit until all its child processes have exited, even if the 5-second timeout elapses and we have to send SIGKILL. There is no great value in having the postmaster process quit sooner, and doing so can mislead onlookers into thinking that the cluster is fully terminated when actually some child processes still survive. This effect might explain recent test failures on buildfarm member hamster, wherein we failed to restart a cluster just after shutting it down with "pg_ctl stop -m immediate". I also did a bit of code review/beautification, including fixing a faulty use of the Max() macro on a volatile expression. Back-patch to 9.4. In older branches, the postmaster never waited for children to exit during immediate shutdowns, and changing that would be too much of a behavioral change.
* Clamp autovacuum launcher sleep time to 5 minutesAlvaro Herrera2015-06-19
| | | | | | | | | | | | | | | This avoids the problem that it might go to sleep for an unreasonable amount of time in unusual conditions like the server clock moving backwards an unreasonable amount of time. (Simply moving the server clock forward again doesn't solve the problem unless you wake up the autovacuum launcher manually, say by sending it SIGHUP). Per trouble report from Prakash Itnal in https://www.postgresql.org/message-id/CAHC5u79-UqbapAABH2t4Rh2eYdyge0Zid-X=Xz-ZWZCBK42S0Q@mail.gmail.com Analyzed independently by Haribabu Kommi and Tom Lane.
* Fix corner case in autovacuum-forcing logic for multixact wraparound.Robert Haas2015-06-19
| | | | | | | | | | | | | | | Since find_multixact_start() relies on SimpleLruDoesPhysicalPageExist(), and that function looks only at the on-disk state, it's possible for it to fail to find a page that exists in the in-memory SLRU that has not been written yet. If that happens, SetOffsetVacuumLimit() will erroneously decide to force emergency autovacuuming immediately. We should probably fix find_multixact_start() to consider the data cached in memory as well as on the on-disk state, but that's no excuse for SetOffsetVacuumLimit() to be stupid about the case where it can no longer read the value after having previously succeeded in doing so. Report by Andres Freund.
* Check for out of memory when allocating sqlca.Michael Meskes2015-06-15
| | | | Patch by Michael Paquier
* Fix memory leak in ecpglib's connect function.Michael Meskes2015-06-15
| | | | Patch by Michael Paquier
* Fix intoasc() in Informix compat lib. This function used to be a noop.Michael Meskes2015-06-13
| | | | Patch by Michael Paquier
* Fixed some memory leaks in ECPG.Michael Meskes2015-06-13
| | | | Patch by Michael Paquier
* Improve error message and hint for ALTER COLUMN TYPE can't-cast failure.Tom Lane2015-06-12
| | | | | | | | | | We already tried to improve this once, but the "improved" text was rather off-target if you had provided a USING clause. Also, it seems helpful to provide the exact text of a suggested USING clause, so users can just copy-and-paste it when needed. Per complaint from Keith Rarick and a suggestion from Merlin Moncure. Back-patch to 9.2 where the current wording was adopted.
* Fix typo in comment.Kevin Grittner2015-06-10
| | | | Backpatch to 9.4 to minimize possible conflicts.
* Stamp 9.4.4.REL9_4_4Tom Lane2015-06-09
|
* Release notes for 9.4.4, 9.3.9, 9.2.13, 9.1.18, 9.0.22.Tom Lane2015-06-09
|
* Report more information if pg_perm_setlocale() fails at startup.Tom Lane2015-06-09
| | | | | | We don't know why a few Windows users have seen this fail, but the taciturnity of the error message certainly isn't helping debug it. Let's at least find out which LC category isn't working.
* Allow HotStandbyActiveInReplay() to be called in single user mode.Andres Freund2015-06-08
| | | | | | | | | | | | HotStandbyActiveInReplay, introduced in 061b079f, only allowed WAL replay to happen in the startup process, missing the single user case. This buglet is fairly harmless as it only causes problems when single user mode in an assertion enabled build is used to replay a btree vacuum record. Backpatch to 9.2. 061b079f was backpatched further, but the assertion was not.
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-07 07:33:39 +0000