aboutsummaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAge
* Remove remnants of a JENTRY_ISFIRST flag bit.Heikki Linnakangas2014-08-15
| | | | I removed the flag earlier, but missed a few references in jsonb.h.
* Set shared library path for in-tree TAP testsPeter Eisentraut2014-08-15
| | | | | | When the TAP tests are run in-tree (make check), set the shared library path using the appropriate environment variable, using a logic similar to pg_regress, so that the right libraries are used.
* Add sortsupport routines for text.Robert Haas2014-08-14
| | | | | | | This provides a small but worthwhile speedup when sorting text, at least in cases to which the sortsupport machinery applies. Robert Haas and Peter Geoghegan
* Fix help message in pg_ctl.Fujii Masao2014-08-14
| | | | | | | | | Previously the help message described that -m is an option for "stop", "restart" and "promote" commands in pg_ctl. But actually that's not an option for "promote". So this commit fixes that incorrect description in the help message. Back-patch to 9.3 where the incorrect description was added.
* Fix whitespacePeter Eisentraut2014-08-13
|
* Add some noreturn attributes based on compiler recommendationsPeter Eisentraut2014-08-13
|
* Prevent memory leaks in parseRelOptions().Tom Lane2014-08-13
| | | | | | | | | | | | | | | | parseRelOptions() tended to leak memory in the caller's context. Most of the time this doesn't really matter since the caller's context is at most query-lifespan, and the function won't be invoked very many times. However, when testing with CLOBBER_CACHE_RECURSIVELY, the same relcache entry can get rebuilt a *lot* of times in one query, leading to significant intraquery memory bloat if it has any reloptions. Noted while investigating a related report from Tomas Vondra. In passing, get rid of some Asserts that are redundant with the one done by deconstruct_array(). As with other patches to avoid leaks in CLOBBER_CACHE testing, it doesn't really seem worth back-patching this.
* Prevent memory leaks in RelationGetIndexList, RelationGetIndexAttrBitmap.Tom Lane2014-08-13
| | | | | | | | | | | | | | | | | When replacing rd_indexlist, rd_indexattr, etc, we neglected to pfree any old value of these fields. Under ordinary circumstances, the old value would always be NULL, so this seemed reasonable enough. However, in cases where we're rebuilding a system catalog's relcache entry and another cache flush occurs on that same catalog meanwhile, it's possible for the field to not be NULL when we return to the outer level, because we already refilled it while recovering from the inner flush. This leads to a fairly small session-lifespan leak in CacheMemoryContext. In real-world usage the leak would be too small to notice; but in testing with CLOBBER_CACHE_RECURSIVELY the leakage can add up to the point of causing OOM failures, as reported by Tomas Vondra. The issue has been there a long time, but it only seems worth fixing in HEAD, like the previous fix in this area (commit 078b2ed291c758e7).
* Expose -S option in pg_receivexlog.Fujii Masao2014-08-13
| | | | | | | | | | | | This option is equivalent to --slot option which pg_receivexlog has already supported, which specifies the replication slot to use for WAL streaming. pg_recvlogical has already supported both options, and this commit makes pg_receivexlog consistent with pg_recvlogical regarding the slot option. Back-patch to 9.4 where the slot option was added. Michael Paquier
* pg_recvlogical message and code improvements.Andres Freund2014-08-12
| | | | | | | | | | | | Some error messages complained about --init and --stop being used whereas the --create and --drop are the correct verbs. Fix that. Also a XLogRecPtr was tested in a boolean fashion instead of being compared to InvalidXLogRecPtr. Backpatch to 9.4 where pg_recvlogical was introduced. Michael Paquier
* Be less aggressive in asking for feedback of logical walsender clients.Andres Freund2014-08-12
| | | | | | | | | | | | | | | | | | When doing logical decoding using START_LOGICAL_REPLICATION in a walsender process the walsender sometimes was sending out keepalive messages too frequently. Asking for feedback every time. WalSndWaitForWal() sends out keepalive messages when it's waiting for new WAL to be generated locally when it sees that the remote side hasn't yet flushed WAL up to the local position. That generally is good but causes problems if the remote side only writes but doesn't flush changes yet. So check for both remote write and flush position. Additionally we've asked for feedback to the keepalive message which isn't warranted when waiting for WAL in contrast to preventing timeouts because of wal_sender_timeout. Complaint and patch by Steve Singer.
* Change first call of ProcessConfigFile so as to process only data_directory.Fujii Masao2014-08-12
| | | | | | | | | | | | | | | | | | | | | | | When both postgresql.conf and postgresql.auto.conf have their own entry of the same parameter, PostgreSQL uses the entry in postgresql.auto.conf because it appears last in the configuration scan. IOW, the other entries which appear earlier are ignored. But, previously, ProcessConfigFile() detected the invalid settings of even those unused entries and emitted the error messages complaining about them, at postmaster startup. Complaining about the entries to ignore is basically useless. This problem happened because ProcessConfigFile() was called twice at postmaster startup and the first call read only postgresql.conf. That is, the first call could check the entry which might be ignored eventually by the second call which read both postgresql.conf and postgresql.auto.conf. To work around the problem, this commit changes ProcessConfigFile so that its first call processes only data_directory and the second one does all the entries. It's OK to process data_directory in the first call because it's ensured that data_directory doesn't exist in postgresql.auto.conf. Back-patch to 9.4 where postgresql.auto.conf was added. Patch by me. Review by Amit Kapila
* Add tab-completion for \unset and valid setting values of psql variables.Fujii Masao2014-08-12
| | | | | | | | | | | | | This commit also changes tab-completion for \set so that it displays all the special variables like COMP_KEYWORD_CASE. Previously it displayed only variables having the set values. Which was not user-friendly for those who want to set the unset variables. This commit also changes tab-completion for :variable so that only the variables having the set values are displayed. Previously even unset variables were displayed. Pavel Stehule, modified by me.
* Break out OpenSSL-specific code to separate files.Heikki Linnakangas2014-08-11
| | | | | | | | | | | | | | | | | | | This refactoring is in preparation for adding support for other SSL implementations, with no user-visible effects. There are now two #defines, USE_OPENSSL which is defined when building with OpenSSL, and USE_SSL which is defined when building with any SSL implementation. Currently, OpenSSL is the only implementation so the two #defines go together, but USE_SSL is supposed to be used for implementation-independent code. The libpq SSL code is changed to use a custom BIO, which does all the raw I/O, like we've been doing in the backend for a long time. That makes it possible to use MSG_NOSIGNAL to block SIGPIPE when using SSL, which avoids a couple of syscall for each send(). Probably doesn't make much performance difference in practice - the SSL encryption is expensive enough to mask the effect - but it was a natural result of this refactoring. Based on a patch by Martijn van Oosterhout from 2006. Briefly reviewed by Alvaro Herrera, Andreas Karlsson, Jeff Janes.
* Clean up handling of unknown-type inputs in json_build_object and friends.Tom Lane2014-08-09
| | | | | | | | There's actually no need for any special case for unknown-type literals, since we only need to push the value through its output function and unknownout() works fine. The code that was here was completely bizarre anyway, and would fail outright in cases that should work, not to mention suffering from some copy-and-paste bugs.
* Further cleanup of JSON-specific error messages.Tom Lane2014-08-09
| | | | | | | | | | | | | | | | | | Fix an obvious typo in json_build_object()'s complaint about invalid number of arguments, and make the errhint a bit more sensible too. Per discussion about how to word the improved hint, change the few places in the documentation that refer to JSON object field names as "names" to say "keys" instead, since that's what we've said in the vast majority of places in the docs. Arguably "name" is more correct, since that's the terminology used in RFC 7159; but we're stuck with "key" in view of the naming of json_object_keys() so let's at least be self-consistent. I adjusted a few code comments to match this as well, and failed to resist the temptation to clean up some odd whitespace choices in the same area, as well as a useless duplicate PG_ARGISNULL() check. There's still quite a bit of code that uses the phrase "field name" in non-user- visible ways, so I left those usages alone.
* Reject duplicate column names in foreign key referenced-columns lists.Tom Lane2014-08-09
| | | | | | | | | | | | | Such cases are disallowed by the SQL spec, and even if we wanted to allow them, the semantics seem ambiguous: how should the FK columns be matched up with the columns of a unique index? (The matching could be significant in the presence of opclasses with different notions of equality, so this issue isn't just academic.) However, our code did not previously reject such cases, but instead would either fail to match to any unique index, or generate a bizarre opclass-lookup error because of sloppy thinking in the index-matching code. David Rowley
* Small message fixesPeter Eisentraut2014-08-09
|
* Add -F option to pg_receivexlog, for specifying fsync interval.Fujii Masao2014-08-08
| | | | | | | | | This allows us to specify the maximum time to issue fsync to ensure the received WAL file is safely flushed to disk. Without this, pg_receivexlog always flushes WAL file only when it's closed and which can cause WAL data to be lost at the event of a crash. Furuya Osamu, heavily modified by me.
* pg_upgrade: prevent oid conflicts with new-cluster TOAST tablesBruce Momjian2014-08-07
| | | | | | | | Previously, TOAST tables only required in the new cluster could cause oid conflicts if they were auto-numbered and a later conflicting oid had to be assigned. Backpatch through 9.3
* Improve comment.Heikki Linnakangas2014-08-07
| | | | | | Based on the old comment, it took me a while to figure out what the problem was. The importnat detail is that SSL_read() can return WANT_READ even though some raw data was received from the socket.
* Add PG_RETURN_UINT16 macro.Robert Haas2014-08-06
| | | | Manuel Kniep
* Don't require sort support functions to provide a comparator.Robert Haas2014-08-06
| | | | | | | | | This could be useful for datatypes like text, where we might want to optimize for some collations but not others. However, this patch doesn't introduce any new sortsupport functions that work this way; it merely revises the code so that future patches may do so. Patch by me. Review by Peter Geoghegan.
* Fix alternate regression test output file.Robert Haas2014-08-06
| | | | | | Commit 0ef99bdce3a6cd3195d7df12093042c16328c71c broke this. Jeff Janes
* 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
* 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.
* 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.
* 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.
* 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).
* 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
* 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().
* 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.
* 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.
* 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.
generated by cgit v1.2.3 (git 2.25.1) at 2025-06-04 07:38:55 +0000