summaryrefslogtreecommitdiff
path: root/src/include
Commit message (Collapse)AuthorAgeFilesLines
* Create a GUC parameter temp_tablespaces that allows selection of theTom Lane2007-06-036-12/+17
| | | | | | | | | | tablespace(s) in which to store temp tables and temporary files. This is a list to allow spreading the load across multiple tablespaces (a random list element is chosen each time a temp object is to be created). Temp files are not stored in per-database pgsql_tmp/ directories anymore, but per-tablespace directories. Jaime Casanova and Albert Cervera, with review by Bernd Helmle and Tom Lane.
* Allow leading and trailing whitespace in the input to the booleanNeil Conway2007-06-014-5/+15
| | | | | | | type. Also, add explicit casts between boolean and text/varchar. Both of these changes are for conformance with SQL:2003. Update the regression tests, bump the catversion.
* Make CREATE/DROP/RENAME DATABASE wait a little bit to see if other backendsTom Lane2007-06-011-2/+2
| | | | | | | will exit before failing because of conflicting DB usage. Per discussion, this seems a good idea to help mask the fact that backend exit takes nonzero time. Remove a couple of thereby-obsoleted sleeps in contrib and PL regression test sequences.
* Buy back some of the cycles spent in more-expensive hash functions byTom Lane2007-06-011-1/+3
| | | | | | | selecting power-of-2, rather than prime, numbers of buckets in hash joins. If the hash functions are doing their jobs properly by making all hash bits equally random, this is good enough, and it saves expensive integer division and modulus operations.
* Fix several hash functions that were taking chintzy shortcuts instead ofTom Lane2007-06-012-3/+4
| | | | | | | | | | | | | delivering a well-randomized hash value. I got religion on this after observing that performance of multi-batch hash join degrades terribly if the higher-order bits of hash values aren't random, as indeed was true for say hashes of small integer values. It's now expected and documented that hash functions should use hash_any or some comparable method to ensure that all bits of their output are about equally random. initdb forced because this change invalidates existing hash indexes. For the same reason, this isn't back-patchable; the hash join performance problem will get a band-aid fix in the back branches.
* Change build_index_pathkeys() so that the expressions it builds to representTom Lane2007-05-311-5/+7
| | | | | | | | | | | | | index key columns always have the type expected by the index's associated operators, ie, we add RelabelType nodes when dealing with binary-compatible index opclasses. This is needed to get varchar indexes to play nicely with the new EquivalenceClass machinery, as per recent gripe from Josh Berkus that CVS HEAD was failing to match a varchar index column to a constant restriction in the query. It seems likely that this change will allow removal of a lot of ugly ad-hoc RelabelType-stripping that the planner has traditionally done while matching expressions to other expressions, but I'll worry about that some other day.
* Make large sequential scans and VACUUMs work in a limited-size "ring" ofTom Lane2007-05-308-19/+51
| | | | | | | | | | | | | | | | | | | | | | | buffers, rather than blowing out the whole shared-buffer arena. Aside from avoiding cache spoliation, this fixes the problem that VACUUM formerly tended to cause a WAL flush for every page it modified, because we had it hacked to use only a single buffer. Those flushes will now occur only once per ring-ful. The exact ring size, and the threshold for seqscans to switch into the ring usage pattern, remain under debate; but the infrastructure seems done. The key bit of infrastructure is a new optional BufferAccessStrategy object that can be passed to ReadBuffer operations; this replaces the former StrategyHintVacuum API. This patch also changes the buffer usage-count methodology a bit: we now advance usage_count when first pinning a buffer, rather than when last unpinning it. To preserve the behavior that a buffer's lifetime starts to decrease when it's released, the clock sweep code is modified to not decrement usage_count of pinned buffers. Work not done in this commit: teach GiST and GIN indexes to use the vacuum BufferAccessStrategy for vacuum-driven fetches. Original patch by Simon, reworked by Heikki and again by Tom.
* Fix trivial misspelling in comment.Tom Lane2007-05-301-2/+2
|
* Fix a bug in input processing for the "interval" type. Previously,Neil Conway2007-05-291-11/+15
| | | | | | | | "microsecond" and "millisecond" units were not considered valid input by themselves, which caused inputs like "1 millisecond" to be rejected erroneously. Update the docs, add regression tests, and backport to 8.2 and 8.1
* Ooops, I was too busy worrying about getting the transactional infrastructureTom Lane2007-05-271-1/+2
| | | | | right to think carefully about how insert and delete counts map to n_live_tuples. Of course a deletion should reduce n_live_tuples.
* pgstat's on-proc-exit hook has to execute after the last transaction commitTom Lane2007-05-271-1/+3
| | | | | | | or abort within a backend; rearrange InitPostgres processing to make it so. Revealed by just-added Asserts along with ECPG regression tests (hm, I wonder why the core regression tests didn't expose it?). This possibly is another reason for missing stats updates ...
* Fix up pgstats counting of live and dead tuples to recognize that committedTom Lane2007-05-275-98/+140
| | | | | | | | | | | and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
* Create hooks to let a loadable plugin monitor (or even replace) the plannerTom Lane2007-05-253-5/+33
| | | | | | | | | | | | | | | and/or create plans for hypothetical situations; in particular, investigate plans that would be generated using hypothetical indexes. This is a heavily-rewritten version of the hooks proposed by Gurjeet Singh for his Index Advisor project. In this formulation, the index advisor can be entirely a loadable module instead of requiring a significant part to be in the core backend, and plans can be generated for hypothetical indexes without requiring the creation and rolling-back of system catalog entries. The index advisor patch as-submitted is not compatible with these hooks, but it needs significant work anyway due to other 8.2-to-8.3 planner changes. With these hooks in the core backend, development of the advisor can proceed as a pgfoundry project.
* Repair planner bug introduced in 8.2 by ability to rearrange outer joins:Tom Lane2007-05-221-1/+8
| | | | | | | | | | | | | | | | | | | in cases where a sub-SELECT inserts a WHERE clause between two outer joins, that clause may prevent us from re-ordering the two outer joins. The code was considering only the joins' own ON-conditions in determining reordering safety, which is not good enough. Add a "delay_upper_joins" flag to OuterJoinInfo to flag that we have detected such a clause and higher-level outer joins shouldn't be permitted to commute with this one. (This might seem overly coarse, but given the current rules for OJ reordering, it's sufficient AFAICT.) The failure case is actually pretty narrow: it needs a WHERE clause within the RHS of a left join that checks the RHS of a lower left join, but is not strict for that RHS (else we'd have simplified the lower join to a plain join). Even then no failure will be manifest unless the planner chooses to rearrange the join order. Per bug report from Adam Terrey.
* Fix best_inner_indexscan to return both the cheapest-total-cost andTom Lane2007-05-222-9/+11
| | | | | | | | | | | | cheapest-startup-cost innerjoin indexscans, and make joinpath.c consider both of these (when different) as the inside of a nestloop join. The original design was based on the assumption that indexscan paths always have negligible startup cost, and so total cost is the only important figure of merit; an assumption that's obviously broken by bitmap indexscans. This oversight could lead to choosing poor plans in cases where fast-start behavior is more important than total cost, such as LIMIT and IN queries. 8.1-vintage brain fade exposed by an example from Chuck D.
* Teach tuplestore.c to throw away data before the "mark" point when the callerTom Lane2007-05-213-5/+9
| | | | | | | | | | | | is using mark/restore but not rewind or backward-scan capability. Insert a materialize plan node between a mergejoin and its inner child if the inner child is a sort that is expected to spill to disk. The materialize shields the sort from the need to do mark/restore and thereby allows it to perform its final merge pass on-the-fly; while the materialize itself is normally cheap since it won't spill to disk unless the number of tuples with equal key values exceeds work_mem. Greg Stark, with some kibitzing from Tom Lane.
* XPath fixes:Peter Eisentraut2007-05-213-7/+7
| | | | | | | | | | | | | | | - Function renamed to "xpath". - Function is now strict, per discussion. - Return empty array in case when XPath expression detects nothing (previously, NULL was returned in such case), per discussion. - (bugfix) Work with fragments with prologue: select xpath('/a', '<?xml version="1.0"?><a /><b />'); // now XML datum is always wrapped with dummy <x>...</x>, XML prologue simply goes away (if any). - Some cleanup. Nikolay Samokhvalov Some code cleanup and documentation work by myself.
* To support external compression of archived WAL data, add a flag bit toTom Lane2007-05-203-6/+15
| | | | | | | | | | | | | | | | | | WAL records that shows whether it is safe to remove full-page images (ie, whether or not an on-line backup was in progress when the WAL entry was made). Also make provision for an XLOG_NOOP record type that can be used to fill in the extra space when decompressing the data for restore. This is the portion of Koichi Suzuki's "full page writes" patch that has to go into the core database. The remainder of that work is two external compression and decompression programs, which for the time being will undergo separate development on pgfoundry. Per discussion. Also, twiddle the handling of BTREE_SPLIT records to ensure it'll be possible to compress them (the previous coding caused essential info to be omitted). The other commonly-used record types seem OK already, with the possible exception of GIN and GIST WAL records, which I don't understand well enough to opine on.
* Have CLUSTER advance the table's relfrozenxid. The new frozen point is theAlvaro Herrera2007-05-181-2/+2
| | | | | | | | | | | | | | | | FreezeXid introduced in a recent commit, so there isn't any data loss in this approach. Doing it causes ALTER TABLE (or rather, the forms of it that cause a full table rewrite) to be affected as well. In this case, the frozen point is RecentXmin, because after the rewrite all the tuples are relabeled with the rewriting transaction's Xid. TOAST tables are fixed automatically as well, as fallout of the way they were already being handled in the respective code paths. With this patch, there is no longer need to VACUUM tables for Xid wraparound purposes that have been cleaned up via TRUNCATE or CLUSTER.
* Temporary fix for the problem that pg_stat_activity, inet_client_addr(),Tom Lane2007-05-171-1/+2
| | | | | | | | | | | | | | and inet_server_addr() fail if the client connected over a "scoped" IPv6 address. In this case getnameinfo() will return a string ending with a poorly-standardized "%something" zone specifier, which these functions try to feed to network_in(), which won't take it. So that we don't lose functionality altogether, suppress the zone specifier before giving the string to network_in(). Per report from Brian Hirt. TODO: probably someday the inet type should support scoped IPv6 addresses, and then this patch should be reverted. Backpatch to 8.2 ... is it worth going further?
* Fix parameter recalculation for Limit nodes: during a ReScan call we mustTom Lane2007-05-171-1/+2
| | | | | | | | | | | | | recompute the limit/offset immediately, so that the updated values are available when the child's ReScan function is invoked. Add a regression test for this, too. Bug is new in HEAD (due to the bounded-sorting patch) so no need for back-patch. I did not do anything about merging this signaling with chgParam processing, but if we were to do that we'd still need to compute the updated values at this point rather than during the first ProcNode call. Per observation and test case from Greg Stark, though I didn't use his patch.
* Move the tuple freezing point in CLUSTER to a point further back in the past,Alvaro Herrera2007-05-172-5/+6
| | | | | | | | | | to avoid losing useful Xid information in not-so-old tuples. This makes CLUSTER behave the same as VACUUM as far a tuple-freezing behavior goes (though CLUSTER does not yet advance the table's relfrozenxid). While at it, move the actual freezing operation in rewriteheap.c to a more appropriate place, and document it thoroughly. This part of the patch from Tom Lane.
* Have TRUNCATE advance the affected table's relfrozenxid to RecentXmin, toAlvaro Herrera2007-05-161-2/+2
| | | | | | | avoid a later needless VACUUM for Xid-wraparound purposes. We can do this since the table is known to be left empty, so no Xid remains on it. Per discussion.
* Update comments for PG_DETOAST_PACKED and VARDATA_ANY on a structuresBruce Momjian2007-05-152-2/+16
| | | | | | | | | that require alignment. Add a paragraph to the "User-Defined Types" chapter on using these macros since it seems like they're a hit. Gregory Stark
* Fix the problem that creating a user-defined type named _foo, followed by oneTom Lane2007-05-121-3/+6
| | | | | | | | | | | named foo, would work but the other ordering would not. If a user-specified type or table name collides with an existing auto-generated array name, just rename the array type out of the way by prepending more underscores. This should not create any backward-compatibility issues, since the cases in which this will happen would have failed outright in prior releases. Also fix an oversight in the arrays-of-composites patch: ALTER TABLE RENAME renamed the table's rowtype but not its array type.
* Fix my oversight in enabling domains-of-domains: ALTER DOMAIN ADD CONSTRAINTTom Lane2007-05-111-1/+5
| | | | | | | | | | | | needs to check the new constraint against columns of derived domains too. Also, make it error out if the domain to be modified is used within any composite-type columns. Eventually we should support that case, but it seems a bit painful, and not suitable for a back-patch. For the moment just let the user know we can't do it. Backpatch to 8.2, which is the only released version that allows nested domains. Possibly the other part should be back-patched further.
* Support arrays of composite types, including the rowtypes of regular tablesTom Lane2007-05-115-176/+191
| | | | | | | | | | | | | | | and views (but not system catalogs, nor sequences or toast tables). Get rid of the hardwired convention that a type's array type is named exactly "_type", instead using a new column pg_type.typarray to provide the linkage. (It still will be named "_type", though, except in odd corner cases such as maximum-length type names.) Along the way, make tracking of owner and schema dependencies for types more uniform: a type directly created by the user has these dependencies, while a table rowtype or auto-generated array type does not have them, but depends on its parent object instead. David Fetter, Andrew Dunstan, Tom Lane
* Reserve some pg_statistic "kind" codes for use by the ESRI ST_GeometryTom Lane2007-05-081-2/+4
| | | | datatype project. Per request from Ale Raza (araza at esri.com).
* Add a hash function for "numeric". Mark the equality operator forNeil Conway2007-05-088-10/+18
| | | | | | | | | | | | | | | numerics as "oprcanhash", and make the corresponding system catalog updates. As a result, hash indexes, hashed aggregation, and hash joins can now be used with the numeric type. Bump the catversion. The only tricky aspect to doing this is writing a correct hash function: it's possible for two Numerics to be equal according to their equality operator, but have different in-memory bit patterns. To cope with this, the hash function doesn't consider the Numeric's "scale" or "sign", and explictly skips any leading or trailing zeros in the Numeric's digit buffer (the current implementation should suppress any such zeros, but it seems unwise to rely upon this). See discussion on pgsql-patches for more details.
* Add a line to the EXPLAIN ANALYZE output for a Sort node, showing theTom Lane2007-05-041-1/+3
| | | | actual sort strategy and amount of space used. By popular demand.
* tas() support for Renesas' M32R processor. Kazuhiro InaokaTom Lane2007-05-042-1/+19
|
* A few fixups in error handling: mark pg_re_throw() as noreturn for gcc,Tom Lane2007-05-042-5/+15
| | | | | | | and for other compilers, insert a dummy exit() call so that they understand PG_RE_THROW() doesn't return. Insert fflush(stderr) in ExceptionalCondition, per recent buildfarm evidence that that might not happen automatically on some platforms. And const-ify ExceptionalCondition's declaration while at it.
* Teach tuplesort.c about "top N" sorting, in which only the first N tuplesTom Lane2007-05-044-7/+14
| | | | | | | | | | need be returned. We keep a heap of the current best N tuples and sift-up new tuples into it as we scan the input. For M input tuples this means only about M*log(N) comparisons instead of M*log(M), not to mention a lot less workspace when N is small --- avoiding spill-to-disk for large M is actually the most attractive thing about it. Patch includes planner and executor support for invoking this facility in ORDER BY ... LIMIT queries. Greg Stark, with some editorialization by moi.
* Tweak hash index AM to use the new ReadOrZeroBuffer bufmgr API when fetchingTom Lane2007-05-031-3/+5
| | | | | | | pages it intends to zero immediately. Just to show there is some use for that function besides WAL recovery :-). Along the way, fold _hash_checkpage and _hash_pageinit calls into _hash_getbuf and friends, instead of expecting callers to do that separately.
* During WAL recovery, when reading a page that we intend to overwrite completelyTom Lane2007-05-021-1/+2
| | | | | | | | | | | | from the WAL data, don't bother to physically read it; just have bufmgr.c return a zeroed-out buffer instead. This speeds recovery significantly, and also avoids unnecessary failures when a page-to-be-overwritten has corrupt page headers on disk. This replaces a former kluge that accomplished the latter by pretending zero_damaged_pages was always ON during WAL recovery; which was OK when the kluge was put in, but is unsafe when restoring a WAL log that was written with full_page_writes off. Heikki Linnakangas
* Fix oversight in PG_RE_THROW processing: it's entirely possible that thereTom Lane2007-05-021-2/+3
| | | | | | | | | | | | | | isn't any place to throw the error to. If so, we should treat the error as FATAL, just as we would have if it'd been thrown outside the PG_TRY block to begin with. Although this is clearly a *potential* source of bugs, it is not clear at the moment whether it is an *actual* source of bugs; there may not presently be any PG_TRY blocks in code that can be reached with no outer longjmp catcher. So for the moment I'm going to be conservative and not back-patch this. The change breaks ABI for users of PG_RE_THROW and hence might create compatibility problems for loadable modules, so we should not put it into released branches without proof that it's needed.
* Change the timestamps recorded in transaction commit/abort xlog recordsTom Lane2007-04-303-6/+8
| | | | | | | | | from time_t to TimestampTz representation. This provides full gettimeofday() resolution of the timestamps, which might be useful when attempting to do point-in-time recovery --- previously it was not possible to specify the stop point with sub-second resolution. But mostly this is to get rid of TimestampTz-to-time_t conversion overhead during commit. Per my proposal of a day or two back.
* Fix oversight in my patch of yesterday: forgot to ensure that stats wouldTom Lane2007-04-301-2/+2
| | | | still be forced out at backend exit.
* Implement rate-limiting logic on how often backends will attempt to sendTom Lane2007-04-302-2/+6
| | | | | | | | | | | | | | messages to the stats collector. This avoids the problem that enabling stats_row_level for autovacuum has a significant overhead for short read-only transactions, as noted by Arjen van der Meijden. We can avoid an extra gettimeofday call by piggybacking on the one done for WAL-logging xact commit or abort (although that doesn't help read-only transactions, since they don't WAL-log anything). In my proposal for this, I noted that we could change the WAL log entries for commit/abort to record full TimestampTz precision, instead of only time_t as at present. That's not done in this patch, but will be committed separately.
* Modify processing of DECLARE CURSOR and EXPLAIN so that they can resolve theTom Lane2007-04-273-11/+20
| | | | | | | | | | | | | | types of unspecified parameters when submitted via extended query protocol. This worked in 8.2 but I had broken it during plancache changes. DECLARE CURSOR is now treated almost exactly like a plain SELECT through parse analysis, rewrite, and planning; only just before sending to the executor do we divert it away to ProcessUtility. This requires a special-case check in a number of places, but practically all of them were already special-casing SELECT INTO, so it's not too ugly. (Maybe it would be a good idea to merge the two by treating IntoClause as a form of utility statement? Not going to worry about that now, though.) That approach doesn't work for EXPLAIN, however, so for that I punted and used a klugy solution of running parse analysis an extra time if under extended query protocol.
* Fix dynahash.c to suppress hash bucket splits while a hash_seq_search() scanTom Lane2007-04-262-3/+19
| | | | | | | | | | | | | | | | | | | | | | | is in progress on the same hashtable. This seems the least invasive way to fix the recently-recognized problem that a split could cause the scan to visit entries twice or (with much lower probability) miss them entirely. The only field-reported problem caused by this is the "failed to re-find shared lock object" PANIC in COMMIT PREPARED reported by Michel Dorochevsky, which was caused by multiply visited entries. However, it seems certain that mdsync() is vulnerable to missing required fsync's due to missed entries, and I am fearful that RelationCacheInitializePhase2() might be at risk as well. Because of that and the generalized hazard presented by this bug, back-patch all the supported branches. Along the way, fix pg_prepared_statement() and pg_cursor() to not assume that the hashtables they are examining will stay static between calls. This is risky regardless of the newly noted dynahash problem, because hash_seq_search() has never promised to cope with deletion of table entries other than the just-returned one. There may be no bug here because the only supported way to call these functions is via ExecMakeTableFunctionResult() which will cycle them to completion before doing anything very interesting, but it seems best to get rid of the assumption. This affects 8.2 and HEAD only, since those functions weren't there earlier.
* Rename the newly-added commands for discarding session state.Neil Conway2007-04-263-2/+41
| | | | | | | | RESET SESSION, RESET PLANS, and RESET TEMP are now DISCARD ALL, DISCARD PLANS, and DISCARD TEMP, respectively. This is to avoid confusion with the pre-existing RESET variants: the DISCARD commands are not actually similar to RESET. Patch from Marko Kreen, with some minor editorialization.
* Some further performance tweaks for planning large inheritance trees thatTom Lane2007-04-211-1/+19
| | | | | | | | are mostly excluded by constraints: do the CE test a bit earlier to save some adjust_appendrel_attrs() work on excluded children, and arrange to use array indexing rather than rt_fetch() to fetch RTEs in the main body of the planner. The latter is something I'd wanted to do for awhile anyway, but seeing list_nth_cell() as 35% of the runtime gets one's attention.
* Make configuration parameters fall back to their default values when theyPeter Eisentraut2007-04-211-4/+7
| | | | | | are removed from the configuration file. Joachim Wieland
* Repair PANIC condition in hash indexes when a previous index extension attemptTom Lane2007-04-191-1/+2
| | | | | | | | | | | failed (due to lock conflicts or out-of-space). We might have already extended the index's filesystem EOF before failing, causing the EOF to be beyond what the metapage says is the last used page. Hence the invariant maintained by the code needs to be "EOF is at or beyond last used page", not "EOF is exactly the last used page". Problem was created by my patch of 2006-11-19 that attempted to repair bug #2737. Since that was back-patched to 7.4, this needs to be as well. Per report and test case from Vlastimil Krejcir.
* Enable configurable log of autovacuum actions. Initial patch from SimonAlvaro Herrera2007-04-181-1/+3
| | | | Riggs, additional code and docs by me. Per discussion.
* Enable IPV6 for all MSVC builds, including the VC6 libpq-only build.Magnus Hagander2007-04-161-2/+1
| | | | Per request from Hiroshi Saito.
* Add a multi-worker capability to autovacuum. This allows multiple workerAlvaro Herrera2007-04-164-4/+17
| | | | | | | | | | | | | | | | | | processes to be running simultaneously. Also, now autovacuum processes do not count towards the max_connections limit; they are counted separately from regular processes, and are limited by the new GUC variable autovacuum_max_workers. The launcher now has intelligence to launch workers on each database every autovacuum_naptime seconds, limited only on the max amount of worker slots available. Also, the global worker I/O utilization is limited by the vacuum cost-based delay feature. Workers are "balanced" so that the total I/O consumption does not exceed the established limit. This part of the patch was contributed by ITAGAKI Takahiro. Per discussion.
* Make plancache store cursor options so it can pass them to planner duringTom Lane2007-04-162-2/+6
| | | | | | a replan. I had originally thought this was not necessary, but the new SPI facilities create a path whereby queries planned with non-default options can get into the cache, so it is necessary.
* Support scrollable cursors (ie, 'direction' clause in FETCH) in plpgsql.Tom Lane2007-04-161-1/+2
| | | | Pavel Stehule, reworked a bit by Tom.
View Lorry Controller Status