aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAge
...
* Refactor pg_receivexlog main loop code, for readability, take 2.Fujii Masao2014-08-06
| | | | | | | | Previously the source codes for processing the received data and handling the end of stream were included in pg_receivexlog main loop. This commit splits out them as separate functions. This is useful for improving the readability of main loop code and making the future pg_receivexlog-related patch simpler.
* Change ParseConfigFp() so that it doesn't process unused entry of each ↵Fujii Masao2014-08-06
| | | | | | | | | | | | | | | | | | | | | | | | | | parameter. When more than one setting entries of same parameter exist in the configuration file, PostgreSQL uses only entry appearing last in configuration file scan. Since the other entries are not used, ParseConfigFp() doesn't need to process them, but previously it did that. This problematic behavior caused the configuration file scan to detect invalid settings of unused entries (e.g., existence of multiple entries of PGC_POSTMASTER parameter) and log the messages complaining about them. This commit changes the configuration file scan so that it processes only last entry of each parameter. Note that when multiple entries of same parameter exist both in postgresql.conf and postgresql.auto.conf, unused entries in postgresql.conf are still processed only at postmaster startup. The problem has existed since old version, but a user is more likely to encounter it since 9.4 where ALTER SYSTEM command was introduced. So back-patch to 9.4. Amit Kapila, slightly modified by me. Per report from Christoph Berg.
* Fix typo in C comment.Kevin Grittner2014-08-05
|
* Improve some JSON error messages.Robert Haas2014-08-05
| | | | | | | These messages are new in 9.4, which hasn't been released yet, so back-patch to REL9_4_STABLE. Daniele Varrazzo
* pg_upgrade: assume user is install userBruce Momjian2014-08-04
| | | | | | The user specified to the upgrade was effectively the install user, but that was not clearly stated in the comments, documentation, or error messages.
* pg_upgrade: remove reference to autovacuum_multixact_freeze_max_ageBruce Momjian2014-08-04
| | | | | | | | | | | | | | | autovacuum_multixact_freeze_max_age was added as a pg_ctl start parameter in 9.3.X to prevent autovacuum from running. However, only some 9.3.X releases have autovacuum_multixact_freeze_max_age as it was added in a minor PG 9.3 release. It also isn't needed because -b turns off autovacuum in 9.1+. Without this fix, trying to upgrade from an early 9.3 release to 9.4 would fail. Report by EDB Backpatch through 9.3
* Windows doesn't have M_PI; define it ourselves when needed.Heikki Linnakangas2014-08-04
| | | | This should fix the Windows build, broken by commit ed802e7d.
* Add missing PQclear() calls into pg_receivexlog.Fujii Masao2014-08-02
| | | | Back-patch to 9.3.
* Fix bug in pg_receivexlog --verbose.Fujii Masao2014-08-02
| | | | | | | | | In 9.2, pg_receivexlog with verbose option has emitted the messages at the end of each WAL file. But the commit 0b63291 suppressed such messages by mistake. This commit fixes the bug so that pg_receivexlog --verbose outputs such messages again. Back-patch to 9.3 where the bug was added.
* Fix typo in user manualHeikki Linnakangas2014-08-01
|
* Move log_newpage and log_newpage_buffer to xlog.c.Heikki Linnakangas2014-07-31
| | | | | | | | | | | log_newpage is used by many indexams, in addition to heap, but for historical reasons it's always been part of the heapam rmgr. Starting with 9.3, we have another WAL record type for logging an image of a page, XLOG_FPI. Simplify things by moving log_newpage and log_newpage_buffer to xlog.c, and switch to using the XLOG_FPI record type. Bump the WAL version number because the code to replay the old HEAP_NEWPAGE records is removed.
* Avoid wholesale autovacuuming when autovacuum is nominally off.Tom Lane2014-07-30
| | | | | | | | | | | | | When autovacuum is nominally off, we will still launch autovac workers to vacuum tables that are at risk of XID wraparound. But after we'd done that, an autovac worker would proceed to autovacuum every table in the targeted database, if they meet the usual thresholds for autovacuuming. This is at best pretty unexpected; at worst it delays response to the wraparound threat. Fix it so that if autovacuum is nominally off, we *only* do forced vacuums and not any other work. Per gripe from Andrey Zhidenkov. This has been like this all along, so back-patch to all supported branches.
* pgbench: Allow \setrandom to generate Gaussian/exponential distributions.Robert Haas2014-07-30
| | | | Mitsumasa KONDO and Fabien COELHO, with further wordsmithing by me.
* Fix mishandling of background worker PGPROCs in EXEC_BACKEND builds.Robert Haas2014-07-30
| | | | | | | | | | InitProcess() relies on IsBackgroundWorker to decide whether the PGPROC for a new backend should be taken from ProcGlobal's freeProcs or from bgworkerFreeProcs. In EXEC_BACKEND builds, InitProcess() is called sooner than in non-EXEC_BACKEND builds, and IsBackgroundWorker wasn't getting initialized soon enough. Report by Noah Misch. Diagnosis and fix by me.
* doc: Clean up some recently added PL/pgSQL documentationPeter Eisentraut2014-07-29
| | | | | | | | - Capitalize titles consistently. - Fix some grammar. - Group "Obtaining Information About an Error" under "Trapping Errors", but make "Obtaining the Call Stack Context Information" its own section, since it's not about errors.
* pg_upgrade: improve C comment wordingBruce Momjian2014-07-29
|
* Avoid uselessly looking up old LOCK_ONLY multixactsAlvaro Herrera2014-07-29
| | | | | | | | | | | | | Commit 0ac5ad5134f2 removed an optimization in multixact.c that skipped fetching members of MultiXactId that were older than our OldestVisibleMXactId value. The reason this was removed is that it is possible for multixacts that contain updates to be older than that value. However, if the caller is certain that the multi does not contain an update (because the infomask bits say so), it can pass this info down to GetMultiXactIdMembers, enabling it to use the old optimization. Pointed out by Andres Freund in 20131121200517.GM7240@alap2.anarazel.de
* Simplify multixact freezing a bitAlvaro Herrera2014-07-29
| | | | | | | | | | Testing for abortedness of a multixact member that's being frozen is unnecessary: we only need to know whether the transaction is still in progress or committed to determine whether it must be kept or not. This let us simplify the code a bit and avoid a useless TransactionIdDidAbort test. Suggested by Andres Freund awhile back.
* Oops, fix recoveryStopsBefore functions for regular commits.Heikki Linnakangas2014-07-29
| | | | | Pointed out by Tom Lane. Backpatch to 9.4, the code was structured differently in earlier branches and didn't have this mistake.
* Treat 2PC commit/abort the same as regular xacts in recovery.Heikki Linnakangas2014-07-29
| | | | | | | | | | | | | | | | | There were several oversights in recovery code where COMMIT/ABORT PREPARED records were ignored: * pg_last_xact_replay_timestamp() (wasn't updated for 2PC commits) * recovery_min_apply_delay (2PC commits were applied immediately) * recovery_target_xid (recovery would not stop if the XID used 2PC) The first of those was reported by Sergiy Zuban in bug #11032, analyzed by Tom Lane and Andres Freund. The bug was always there, but was masked before commit d19bd29f07aef9e508ff047d128a4046cc8bc1e2, because COMMIT PREPARED always created an extra regular transaction that was WAL-logged. Backpatch to all supported versions (older versions didn't have all the features and therefore didn't have all of the above bugs).
* Reword the sentence for pg_logical_slot_peek_changes function.Fujii Masao2014-07-29
| | | | | | | | | | | Previously the duplicated paragraphs were used next to each other in the document to demonstrate that the changes in the stream were not consumed by pg_logical_slot_peek_changes function. But some users misunderstood that the duplication of the same paragraph was just typo. So this commit rewords the sentence in the latter paragraph for less confusing. Christoph Moench-Tegeder
* Fix obsolete statement in smgr/README.Tom Lane2014-07-28
| | | | | | | Since commit 2d00190495b22e0d0ba351b2cda9c95fb2e3d083, fork numbers are defined in relpath.h not relfilenode.h. Fabrízio de Royes Mello
* doc: Fix up ALTER TABLESPACE reference pagePeter Eisentraut2014-07-26
| | | | | | The documentation of ALTER TABLESPACE ... MOVE was added without any markup, not even paragraph breaks. Fix that, and clarify the text in a few places.
* Fix a performance problem in pg_dump's dump order selection logic.Tom Lane2014-07-25
| | | | | | | | | | | | | | | | | findDependencyLoops() was not bright about cases where there are multiple dependency paths between the same two dumpable objects. In most scenarios this did not hurt us too badly; but since the introduction of section boundary pseudo-objects in commit a1ef01fe163b304760088e3e30eb22036910a495, it was possible for this code to take unreasonable amounts of time (tens of seconds on a database with a couple thousand objects), as reported in bug #11033 from Joe Van Dyk. Joe's particular problem scenario involved "pg_dump -a" mode with long chains of foreign key constraints, but I think that similar problems could arise with other situations as long as there were enough objects. To fix, add a flag array that lets us notice when we arrive at the same object again while searching from a given start object. This simple change seems to be enough to eliminate the performance problem. Back-patch to 9.1, like the patch that introduced section boundary objects.
* Handle WAIT_IO_COMPLETION return from WaitForMultipleObjectsEx().Noah Misch2014-07-25
| | | | | | | | | | | | | | This return code is possible wherever we pass bAlertable = TRUE; it arises when Windows caused the current thread to run an "I/O completion routine" or an "asynchronous procedure call". PostgreSQL does not provoke either of those Windows facilities, hence this bug remaining largely unnoticed, but other local code might do so. Due to a shortage of complaints, no back-patch for now. Per report from Shiv Shivaraju Gowda, this bug can cause PGSemaphoreLock() to PANIC. The bug can also cause select() to report timeout expiration too early, which might confuse pgstat_init() and CheckRADIUSAuth().
* Move PGAC_LDAP_SAFE to config/programs.m4.Noah Misch2014-07-25
| | | | | This restores the style of keeping configure.in free of AC_DEFUN. Per gripe from Tom Lane.
* Prevent shm_mq_send from reading uninitialized memory.Robert Haas2014-07-24
| | | | | | | | | shm_mq_send_bytes didn't invariably initialize *bytes_written before returning, which would cause shm_mq_send to read from uninitialized memory and add the value it found there to mqh->mqh_partial_bytes. This could cause the next attempt to send a message via the queue to fail an assertion (if the queue was detached) or copy data from a garbage pointer value into the queue (if non-blocking mode was in use).
* Fix checkpointer crash in EXEC_BACKEND builds.Robert Haas2014-07-24
| | | | | | | | | | | | | | Nothing in the checkpointer calls InitXLOGAccess(), so WALInsertLocks never got initialized there. Without EXEC_BACKEND, it works anyway because the correct value is inherited from the postmaster, but with EXEC_BACKEND we've got a problem. The problem appears to have been introduced by commit 68a2e52bbaf98f136a96b3a0d734ca52ca440a95. To fix, move the relevant initialization steps from InitXLOGAccess() to XLOGShmemInit(), making this more parallel to what we do elsewhere. Amit Kapila
* Properly remove ephemeral replication slots after a crash restart.Andres Freund2014-07-24
| | | | | | | | | | | | Ephemeral slots - slots that shouldn't survive database restarts - weren't properly cleaned up after a immediate/crash restart. They were ignored in the sense that they weren't restored into memory and thus didn't cause unwanted resource retention; but they prevented a new slot with the same name from being created. Now ephemeral slots are fully removed during startup. Backpatch to 9.4 where replication slots where added.
* Avoid access to already-released lock in LockRefindAndRelease.Robert Haas2014-07-24
| | | | Spotted by Tom Lane.
* docs: Improve documentation of \pset without arguments.Robert Haas2014-07-24
| | | | | | | | | The syntax summary previously failed to clarify that the first argument is also optional. The textual description did mention it, but all the way at the bottom. It fits better with the command overview, so move it there, and fix the summary also. Dilip Kumar, reviewed by Fabien Coelho
* Fix bug where pg_receivexlog goes into busy loop if -s option is set to 0.Fujii Masao2014-07-24
| | | | | | | | | The problem is that pg_receivexlog calls select(2) with timeout=0 and goes into busy loop when --status-interval option is set to 0. This bug was introduced by the commit, 74cbe966fe2d76de1d607d933c98c144dab58769. Per report from Sawada Masahiko
* Fix TAP installcheck tests when current directory name contains spacesPeter Eisentraut2014-07-23
| | | | | This fixes the installcheck part. The check part has additional problems that will be addressed in a separate commit.
* Rearrange documentation paragraph describing pg_relation_size().Tom Lane2014-07-23
| | | | | | | | | | | | Break the list of available options into an <itemizedlist> instead of inline sentences. This is mostly motivated by wanting to ensure that the cross-references to the FSM and VM docs don't cross page boundaries in PDF format; but it seems to me to read more easily this way anyway. I took the liberty of editorializing a bit further while at it. Per complaint from Magnus about 9.0.18 docs not building in A4 format. Patch all active branches so we don't get blind-sided by this particular issue again in future.
* Report success when Windows kill() emulation signals an exiting process.Noah Misch2014-07-23
| | | | | | | | This is consistent with the POSIX verdict that kill() shall not report ESRCH for a zombie process. Back-patch to 9.0 (all supported versions). Test code from commit d7cdf6ee36adeac9233678fb8f2a112e6678a770 depends on it, and log messages about kill() reporting "Invalid argument" will cease to appear for this not-unexpected condition.
* MSVC: Substitute $(top_builddir) in REGRESS_OPTS.Noah Misch2014-07-23
| | | | | Commit d7cdf6ee36adeac9233678fb8f2a112e6678a770 introduced a usage thereof. Back-patch to 9.0, like that commit.
* Re-enable error for "SELECT ... OFFSET -1".Tom Lane2014-07-22
| | | | | | | | | | | The executor has thrown errors for negative OFFSET values since 8.4 (see commit bfce56eea45b1369b7bb2150a150d1ac109f5073), but in a moment of brain fade I taught the planner that OFFSET with a constant negative value was a no-op (commit 1a1832eb085e5bca198735e5d0e766a3cb61b8fc). Reinstate the former behavior by only discarding OFFSET with a value of exactly 0. In passing, adjust a planner comment that referenced the ancient behavior. Back-patch to 9.3 where the mistake was introduced.
* Check block number against the correct fork in get_raw_page().Tom Lane2014-07-22
| | | | | | | | | | | | | | | | | | get_raw_page tried to validate the supplied block number against RelationGetNumberOfBlocks(), which of course is only right when accessing the main fork. In most cases, the main fork is longer than the others, so that the check was too weak (allowing a lower-level error to be reported, but no real harm to be done). However, very small tables could have an FSM larger than their heap, in which case the mistake prevented access to some FSM pages. Per report from Torsten Foertsch. In passing, make the bad-block-number error into an ereport not elog (since it's certainly not an internal error); and fix sloppily maintained comment for RelationGetNumberOfBlocksInFork. This has been wrong since we invented relation forks, so back-patch to all supported branches.
* Allow empty string object keys in json_object().Andrew Dunstan2014-07-22
| | | | | This makes the behaviour consistent with the json parser, other json-generating functions, and the JSON standards.
* Diagnose incompatible OpenLDAP versions during build and test.Noah Misch2014-07-22
| | | | | | | With OpenLDAP versions 2.4.24 through 2.4.31, inclusive, PostgreSQL backends can crash at exit. Raise a warning during "configure" based on the compile-time OpenLDAP version number, and test the crash scenario in the dblink test suite. Back-patch to 9.0 (all supported versions).
* Unset some local environment variables in TAP testsPeter Eisentraut2014-07-22
| | | | | | Unset environment variables that control message language, so that we can compare some program output with expected strings. This is very similar to what pg_regress does.
* gitattributes: Ignore time zone data files for whitespace checksPeter Eisentraut2014-07-22
| | | | | The latest update introduced some funny whitespace, but since they are externally maintained files, we add them to the list of files to ignore.
* Reject out-of-range numeric timezone specifications.Tom Lane2014-07-21
| | | | | | | | | | | | | | | In commit 631dc390f49909a5c8ebd6002cfb2bcee5415a9d, we started to handle simple numeric timezone offsets via the zic library instead of the old CTimeZone/HasCTZSet kluge. However, we overlooked the fact that the zic code will reject UTC offsets exceeding a week (which seems a bit arbitrary, but not because it's too tight ...). This led to possibly setting session_timezone to NULL, which results in crashes in most timezone-related operations as of 9.4, and crashes in a small number of places even before that. So check for NULL return from pg_tzset_offset() and report an appropriate error message. Per bug #11014 from Duncan Gillis. Back-patch to all supported branches, like the previous patch. (Unfortunately, as of today that no longer includes 8.4.)
* Release notes for 9.3.5, 9.2.9, 9.1.14, 9.0.18, 8.4.22.Tom Lane2014-07-21
|
* Adjust cutoff points in newly-added sanity tests.Tom Lane2014-07-21
| | | | Per recommendation from Andres.
* Defend against bad relfrozenxid/relminmxid/datfrozenxid/datminmxid values.Tom Lane2014-07-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In commit a61daa14d56867e90dc011bbba52ef771cea6770, we fixed pg_upgrade so that it would install sane relminmxid and datminmxid values, but that does not cure the problem for installations that were already pg_upgraded to 9.3; they'll initially have "1" in those fields. This is not a big problem so long as 1 is "in the past" compared to the current nextMultiXact counter. But if an installation were more than halfway to the MXID wrap point at the time of upgrade, 1 would appear to be "in the future" and that would effectively disable tracking of oldest MXIDs in those tables/databases, until such time as the counter wrapped around. While in itself this isn't worse than the situation pre-9.3, where we did not manage MXID wraparound risk at all, the consequences of premature truncation of pg_multixact are worse now; so we ought to make some effort to cope with this. We discussed advising users to fix the tracking values manually, but that seems both very tedious and very error-prone. Instead, this patch adopts two amelioration rules. First, a relminmxid value that is "in the future" is allowed to be overwritten with a full-table VACUUM's actual freeze cutoff, ignoring the normal rule that relminmxid should never go backwards. (This essentially assumes that we have enough defenses in place that wraparound can never occur anymore, and thus that a value "in the future" must be corrupt.) Second, if we see any "in the future" values then we refrain from truncating pg_clog and pg_multixact. This prevents loss of clog data until we have cleaned up all the broken tracking data. In the worst case that could result in considerable clog bloat, but in practice we expect that relfrozenxid-driven freezing will happen soon enough to fix the problem before clog bloat becomes intolerable. (Users could do manual VACUUM FREEZEs if not.) Note that this mechanism cannot save us if there are already-wrapped or already-truncated-away MXIDs in the table; it's only capable of dealing with corrupt tracking values. But that's the situation we have with the pg_upgrade bug. For consistency, apply the same rules to relfrozenxid/datfrozenxid. There are not known mechanisms for these to get messed up, but if they were, the same tactics seem appropriate for fixing them.
* Properly use DEFAULT_EVENT_SOURCE in pgevent.cMagnus Hagander2014-07-21
| | | | | | | This was broken and reverted in a previous commit. The (this time verified) fix is to simly add postgres_fe.h. MauMau, review by Amit Kapila
* Translation updatesPeter Eisentraut2014-07-21
|
* Update SQL features listPeter Eisentraut2014-07-21
|
* Replace "internationalize" with "localize" where appropriatePeter Eisentraut2014-07-20
|
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-07 09:43:52 +0000