aboutsummaryrefslogtreecommitdiff
path: root/src/backend/commands
Commit message (Collapse)AuthorAge
* Introduce the concept of relation forks. An smgr relation can now consistHeikki Linnakangas2008-08-11
| | | | | | | | | | | | | | | | of multiple forks, and each fork can be created and grown separately. The bulk of this patch is about changing the smgr API to include an extra ForkNumber argument in every smgr function. Also, smgrscheduleunlink and smgrdounlink no longer implicitly call smgrclose, because other forks might still exist after unlinking one. The callers of those functions have been modified to call smgrclose instead. This patch in itself doesn't have any user-visible effect, but provides the infrastructure needed for upcoming patches. The additional forks envisioned are a rewritten FSM implementation that doesn't rely on a fixed-size shared memory block, and a visibility map to allow skipping portions of a table in VACUUM that have no dead tuples.
* Support hashing for duplicate-elimination in INTERSECT and EXCEPT queries.Tom Lane2008-08-07
| | | | | | | | | | This completes my project of improving usage of hashing for duplicate elimination (aggregate functions with DISTINCT remain undone, but that's for some other day). As with the previous patches, this means we can INTERSECT/EXCEPT on datatypes that can hash but not sort, and it means that INTERSECT/EXCEPT without ORDER BY are no longer certain to produce sorted output.
* Improve CREATE/DROP/RENAME DATABASE so that when failing because the sourceTom Lane2008-08-04
| | | | | | | | | or target database is being accessed by other users, it tells you whether the "other users" are live sessions or uncommitted prepared transactions. (Indeed, it tells you exactly how many of each, but that's mostly just because it was easy to do so.) This should help forestall the gotcha of not realizing that a prepared transaction is what's blocking the command. Per discussion.
* Rearrange the querytree representation of ORDER BY/GROUP BY/DISTINCT itemsTom Lane2008-08-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | as per my recent proposal: 1. Fold SortClause and GroupClause into a single node type SortGroupClause. We were already relying on them to be struct-equivalent, so using two node tags wasn't accomplishing much except to get in the way of comparing items with equal(). 2. Add an "eqop" field to SortGroupClause to carry the associated equality operator. This is cheap for the parser to get at the same time it's looking up the sort operator, and storing it eliminates the need for repeated not-so-cheap lookups during planning. In future this will also let us represent GROUP/DISTINCT operations on datatypes that have hash opclasses but no btree opclasses (ie, they have equality but no natural sort order). The previous representation simply didn't work for that, since its only indicator of comparison semantics was a sort operator. 3. Add a hasDistinctOn boolean to struct Query to explicitly record whether the distinctClause came from DISTINCT or DISTINCT ON. This allows removing some complicated and not 100% bulletproof code that attempted to figure that out from the distinctClause alone. This patch doesn't in itself create any new capability, but it's necessary infrastructure for future attempts to use hash-based grouping for DISTINCT and UNION/INTERSECT/EXCEPT.
* Require superuser privilege to create base types (but not composites, enums,Tom Lane2008-07-31
| | | | | | | | or domains). This was already effectively required because you had to own the I/O functions, and the I/O functions pretty much have to be written in C since we don't let PL functions take or return cstring. But given the possible security consequences of a malicious type definition, it seems prudent to enforce superuser requirement directly. Per recent discussion.
* Flip the default typispreferred setting from true to false. This affectsTom Lane2008-07-30
| | | | | | | | | only type categories in which the previous coding made *every* type preferred; so there is no change in effective behavior, because the function resolution rules only do something different when faced with a choice between preferred and non-preferred types in the same category. It just seems safer and less surprising to have CREATE TYPE default to non-preferred status ...
* Replace the hard-wired type knowledge in TypeCategory() and IsPreferredType()Tom Lane2008-07-30
| | | | | | | | | | | | | | | | | | | | | with system catalog lookups, as was foreseen to be necessary almost since their creation. Instead put the information into two new pg_type columns, typcategory and typispreferred. Add support for setting these when creating a user-defined base type. The category column is just a "char" (i.e. a poor man's enum), allowing a crude form of user extensibility of the category list: just use an otherwise-unused character. This seems sufficient for foreseen uses, but we could upgrade to having an actual category catalog someday, if there proves to be a huge demand for custom type categories. In this patch I have attempted to hew exactly to the behavior of the previous hardwired logic, except for introducing new type categories for arrays, composites, and enums. In particular the default preferred state for user-defined types remains TRUE. That seems worth revisiting, but it should be done as a separate patch from introducing the infrastructure. Likewise, any adjustment of the standard set of categories should be done separately.
* Add comment about the two different query strings that ExecuteQuery()Tom Lane2008-07-21
| | | | has to deal with.
* Adjust things so that the query_string of a cached plan and the sourceText ofTom Lane2008-07-18
| | | | | | | | | | | | | | | | | | | | | | | | a portal are never NULL, but reliably provide the source text of the query. It turns out that there was only one place that was really taking a short-cut, which was the 'EXECUTE' utility statement. That doesn't seem like a sufficiently critical performance hotspot to justify not offering a guarantee of validity of the portal source text. Fix it to copy the source text over from the cached plan. Add Asserts in the places that set up cached plans and portals to reject null source strings, and simplify a bunch of places that formerly needed to guard against nulls. There may be a few places that cons up statements for execution without having any source text at all; I found one such in ConvertTriggerToFK(). It seems sufficient to inject a phony source string in such a case, for instance ProcessUtility((Node *) atstmt, "(generated ALTER TABLE ADD FOREIGN KEY command)", NULL, false, None_Receiver, NULL); We should take a second look at the usage of debug_query_string, particularly the recently added current_query() SQL function. ITAGAKI Takahiro and Tom Lane
* Implement SQL-spec RETURNS TABLE syntax for functions.Tom Lane2008-07-18
| | | | | | | (Unlike the original submission, this patch treats TABLE output parameters as being entirely equivalent to OUT parameters -- tgl) Pavel Stehule
* Fix previous patch so that it actually works --- consider TRUNCATE foo, ↵Tom Lane2008-07-16
| | | | public.foo
* Add a "provariadic" column to pg_proc to eliminate the remarkably expensiveTom Lane2008-07-16
| | | | | | | | | | need to deconstruct proargmodes for each pg_proc entry inspected by FuncnameGetCandidates(). Fixes function lookup performance regression caused by yesterday's variadic-functions patch. In passing, make pg_proc.probin be NULL, rather than a dummy value '-', in cases where it is not actually used for the particular type of function. This should buy back some of the space cost of the extra column.
* Allow TRUNCATE foo, foo to succeed, per report from Nikhils.Bruce Momjian2008-07-16
|
* Support "variadic" functions, which can accept a variable number of argumentsTom Lane2008-07-16
| | | | | | | | | | | | | | so long as all the trailing arguments are of the same (non-array) type. The function receives them as a single array argument (which is why they have to all be the same type). It might be useful to extend this facility to aggregates, but this patch doesn't do that. This patch imposes a noticeable slowdown on function lookup --- a follow-on patch will fix that by adding a redundant column to pg_proc. Pavel Stehule
* Clean up the use of some page-header-access macros: principally, useTom Lane2008-07-13
| | | | | | | | | | SizeOfPageHeaderData instead of sizeof(PageHeaderData) in places where that makes the code clearer, and avoid casting between Page and PageHeader where possible. Zdenek Kotala, with some additional cleanup by Heikki Linnakangas. I did not apply the parts of the proposed patch that would have resulted in slightly changing the on-disk format of hash indexes; it seems to me that's not a win as long as there's any chance of having in-place upgrade for 8.4.
* More replacements of binary compatible to binary coercible.Peter Eisentraut2008-07-12
|
* Allow binary-coercible types for cast function arguments and return types.Peter Eisentraut2008-07-11
| | | | | | | Document return type of cast functions. Also change documentation to prefer the term "binary coercible" in its present sense instead of the previous term "binary compatible".
* Extend VacAttrStats to allow typanalyze functions to store statistic valuesHeikki Linnakangas2008-07-01
| | | | | | | | of different types than the underlying column. The capability isn't yet used for anything, but will be required by upcoming patch to analyze tsvector columns. Jan Urbanski
* Improve our #include situation by moving pointer types away from theAlvaro Herrera2008-06-19
| | | | | | | corresponding struct definitions. This allows other headers to avoid including certain highly-loaded headers such as rel.h and relscan.h, instead using just relcache.h, heapam.h or genam.h, which are more lightweight and thus cause less unnecessary dependencies.
* Make DROP INDEX lock the parent table before locking the index. This behaviorTom Lane2008-06-15
| | | | | | is necessary to avoid deadlock against ordinary queries, but we'd broken it with recent changes that made the DROP machinery lock the index before arriving at index_drop. Per intermittent buildfarm failures.
* Rearrange ALTER TABLE syntax processing as per my recent proposal: theTom Lane2008-06-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | grammar allows ALTER TABLE/INDEX/SEQUENCE/VIEW interchangeably for all subforms of those commands, and then we sort out what's really legal at execution time. This allows the ALTER SEQUENCE/VIEW reference pages to fully document all the ALTER forms available for sequences and views respectively, and eliminates a longstanding cause of confusion for users. The net effect is that the following forms are allowed that weren't before: ALTER SEQUENCE OWNER TO ALTER VIEW ALTER COLUMN SET/DROP DEFAULT ALTER VIEW OWNER TO ALTER VIEW SET SCHEMA (There's no actual functionality gain here, but formerly you had to say ALTER TABLE instead.) Interestingly, the grammar tables actually get smaller, probably because there are fewer special cases to keep track of. I did not disallow using ALTER TABLE for these operations. Perhaps we should, but there's a backwards-compatibility issue if we do; in fact it would break existing pg_dump scripts. I did however tighten up ALTER SEQUENCE and ALTER VIEW to reject non-sequences and non-views in the new cases as well as a couple of cases where they didn't before. The patch doesn't change pg_dump to use the new syntaxes, either.
* Refactor the handling of the various DropStmt variants so that when multipleTom Lane2008-06-14
| | | | | | | | | | | | | objects are specified, we drop them all in a single performMultipleDeletions call. This makes the RESTRICT/CASCADE checks more relaxed: it's not counted as a cascade if one of the later objects has a dependency on an earlier one. NOTICE messages about such cases go away, too. In passing, fix the permissions check for DROP CONVERSION, which for some reason was never made role-aware, and omitted the namespace-owner exemption too. Alex Hunsaker, with further fiddling by me.
* Refactor XLogOpenRelation() and XLogReadBuffer() in preparation for relationHeikki Linnakangas2008-06-12
| | | | | | | | | | forks. XLogOpenRelation() and the associated light-weight relation cache in xlogutils.c is gone, and XLogReadBuffer() now takes a RelFileNode as argument, instead of Relation. For functions that still need a Relation struct during WAL replay, there's a new function called CreateFakeRelcacheEntry() that returns a fake entry like XLogOpenRelation() used to.
* Move BufferGetPageSize and BufferGetPage from bufpage.h to bufmgr.h. It isAlvaro Herrera2008-06-08
| | | | | | | | | | more logical that way, and also it reduces the amount of unnecessary includes in bufpage.h, which is widely used. Zdenek Kotala. My previous patch to bufpage.h should also have credited him as author, but I forgot (sorry about that).
* ALTER AGGREGATE OWNER seems to have been missed by the last couple ofTom Lane2008-06-08
| | | | | | | patches that dealt with object ownership. It wasn't updating pg_shdepend nor adjusting the aggregate's ACL. In 8.2 and up, fix this permanently by making it use AlterFunctionOwner_oid. In 8.1, the function code wasn't factored that way, so just copy and paste.
* Modify vacuum() to accept a single relation OID instead of a list (which weAlvaro Herrera2008-06-05
| | | | always pass as a single element anyway.) In passing, fix an outdated comment.
* Coercion sanity check in ri_HashCompareOp failed to allow for enums, as perTom Lane2008-05-19
| | | | | example from Rod Taylor. On reflection the correct test here is for any polymorphic type, not specifically ANYARRAY as in the original coding.
* Allow ALTER SEQUENCE START WITH to change the recorded start_value of aTom Lane2008-05-17
| | | | | sequence. This seems an obvious extension to the recent patch, and it makes the code noticeably cleaner and more orthogonal.
* Add a RESTART (without parameter) option to ALTER SEQUENCE, allowing aTom Lane2008-05-16
| | | | | | | | | | | | | | sequence to be reset to its original starting value. This requires adding the original start value to the set of parameters (columns) of a sequence object, which is a user-visible change with potential compatibility implications; it also forces initdb. Also add hopefully-SQL-compatible RESTART/CONTINUE IDENTITY options to TRUNCATE TABLE. RESTART IDENTITY executes ALTER SEQUENCE RESTART for all sequences "owned by" any of the truncated relations. CONTINUE IDENTITY is a no-op option. Zoltan Boszormenyi
* Add support for tracking call counts and elapsed runtime for user-definedTom Lane2008-05-15
| | | | | | | | | | functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
* Move the "instr_time" typedef and associated macros into a new headerTom Lane2008-05-14
| | | | | | | | | file portability/instr_time.h, and add a couple more macros to eliminate some abstraction leakage we formerly had. Also update psql to use this header instead of its own copy of nearly the same code. This commit in itself is just code cleanup and shouldn't change anything. It lays some groundwork for the upcoming function-stats patch, though.
* Improve snapshot manager by keeping explicit track of snapshots.Alvaro Herrera2008-05-12
| | | | | | | | | | | | | There are two ways to track a snapshot: there's the "registered" list, which is used for arbitrary long-lived snapshots; and there's the "active stack", which is used for the snapshot that is considered "active" at any time. This also allows users of snapshots to stop worrying about snapshot memory allocation and freeing, and about using PG_TRY blocks around ActiveSnapshot assignment. This is all done automatically now. As a consequence, this allows us to reset MyProc->xmin when there are no more snapshots registered in the current backend, reducing the impact that long-running transactions have on VACUUM.
* Put back bufmgr.h in bufpage.h -- it is needed by some macros.Alvaro Herrera2008-05-12
| | | | | Remove #include bufmgr.h from (most?) source files which already include bufpage.h.
* Restructure some header files a bit, in particular heapam.h, by removing someAlvaro Herrera2008-05-12
| | | | | | | | | | | | unnecessary #include lines in it. Also, move some tuple routine prototypes and macros to htup.h, which allows removal of heapam.h inclusion from some .c files. For this to work, a new header file access/sysattr.h needed to be created, initially containing attribute numbers of system columns, for pg_dump usage. While at it, make contrib ltree, intarray and hstore header files more consistent with our header style.
* Change the rules for inherited CHECK constraints to be essentially the sameTom Lane2008-05-09
| | | | | | | | | | | | | | | | as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
* Fix REASSIGN OWNED so that it works on procedural languages too.Alvaro Herrera2008-04-29
| | | | | | | The capability for changing language owners is new in 8.3, so that's how far back this needs to be backpatched. Per bug #4132 by Kirill Simonov.
* Fix ALTER TABLE ADD COLUMN ... PRIMARY KEY so that the new column is correctlyTom Lane2008-04-24
| | | | | | | | | | checked to see if it's been initialized to all non-nulls. The implicit NOT NULL constraint was not being checked during the ALTER (in fact, not even if there was an explicit NOT NULL too), because ATExecAddColumn neglected to set the flag needed to make the test happen. This has been broken since the capability was first added, in 8.0. Brendan Jurd, per a report from Kaloyan Iliev.
* Allow float8, int8, and related datatypes to be passed by value on machinesTom Lane2008-04-21
| | | | | | | | | | where Datum is 8 bytes wide. Since this will break old-style C functions (those still using version 0 calling convention) that have arguments or results of these types, provide a configure option to disable it and retain the old pass-by-reference behavior. Likewise, provide a configure option to disable the recently-committed float4 pass-by-value change. Zoltan Boszormenyi, plus configurability stuff by me.
* Modify the float4 datatype to be pass-by-val. Along the way, remove the lastAlvaro Herrera2008-04-18
| | | | | | | | | | | | | | | uses of the long-deprecated float32 in contrib/seg; the definitions themselves are still there, but no longer used. fmgr/README updated to match. I added a CREATE FUNCTION to account for existing seg_center() code in seg.c too, and some tests for it and the neighbor functions. At the same time, remove checks for NULL which are not needed (because the functions are declared STRICT). I had to do some adjustments to contrib's btree_gist too. The choices for representation there are not ideal for changing the underlying types :-( Original patch by Zoltan Boszormenyi, with some adjustments by me.
* Fix rmtree() so that it keeps going after failure to remove any individualTom Lane2008-04-18
| | | | | | file; the idea is that we should clean up as much as we can, even if there's some problem removing one file. Make the error messages a bit less misleading, too. In passing, const-ify function arguments.
* Fix two race conditions between the pending unlink mechanism that was put inHeikki Linnakangas2008-04-18
| | | | | | | | | | | | | | | | | | | | | place to prevent reusing relation OIDs before next checkpoint, and DROP DATABASE. First, if a database was dropped, bgwriter would still try to unlink the files that the rmtree() call by the DROP DATABASE command has already deleted, or is just about to delete. Second, if a database is dropped, and another database is created with the same OID, bgwriter would in the worst case delete a relation in the new database that happened to get the same OID as a dropped relation in the old database. To fix these race conditions: - make rmtree() ignore ENOENT errors. This fixes the 1st race condition. - make ForgetDatabaseFsyncRequests forget unlink requests as well. - force checkpoint on in dropdb on all platforms Since ForgetDatabaseFsyncRequests() is asynchronous, the 2nd change isn't enough on its own to fix the problem of dropping and creating a database with same OID, but forcing a checkpoint on DROP DATABASE makes it sufficient. Per Tom Lane's bug report and proposal. Backpatch to 8.3.
* Cause EXPLAIN's VERBOSE option to print the target list (output column list)Tom Lane2008-04-18
| | | | | | | | | | of each plan node, instead of its former behavior of dumping the internal representation of the plan tree. The latter display is still available for those who really want it (see debug_print_plan), but uses for it are certainly few and and far between. Per discussion. This patch also removes the explain_pretty_print GUC, which is obsoleted by the change.
* Add some code to EXPLAIN to show the targetlist (ie, output columns)Tom Lane2008-04-17
| | | | | | of each plan node. For the moment this is debug support only and is not enabled unless EXPLAIN_PRINT_TLISTS is defined at build time. Later I'll see about the idea of letting EXPLAIN VERBOSE do it.
* Repair two places where SIGTERM exit could leave shared memory stateTom Lane2008-04-16
| | | | | | | | | | | | | | corrupted. (Neither is very important if SIGTERM is used to shut down the whole database cluster together, but there's a problem if someone tries to SIGTERM individual backends.) To do this, introduce new infrastructure macros PG_ENSURE_ERROR_CLEANUP/PG_END_ENSURE_ERROR_CLEANUP that take care of transiently pushing an on_shmem_exit cleanup hook. Also use this method for createdb cleanup --- that wasn't a shared-memory-corruption problem, but SIGTERM abort of createdb could leave orphaned files lying around. Backpatch as far as 8.2. The shmem corruption cases don't exist in 8.1, and the createdb usage doesn't seem important enough to risk backpatching further.
* Push index operator lossiness determination down to GIST/GIN opclassTom Lane2008-04-14
| | | | | | | | | | | "consistent" functions, and remove pg_amop.opreqcheck, as per recent discussion. The main immediate benefit of this is that we no longer need 8.3's ugly hack of requiring @@@ rather than @@ to test weight-using tsquery searches on GIN indexes. In future it should be possible to optimize some other queries better than is done now, by detecting at runtime whether the index match is exact or not. Tom Lane, after an idea of Heikki's, and with some help from Teodor.
* Phase 2 of project to make index operator lossiness be determined at runtimeTom Lane2008-04-13
| | | | | | | | | | | | instead of plan time. Extend the amgettuple API so that the index AM returns a boolean indicating whether the indexquals need to be rechecked, and make that rechecking happen in nodeIndexscan.c (currently the only place where it's expected to be needed; other callers of index_getnext are just erroring out for now). For the moment, GIN and GIST have stub logic that just always sets the recheck flag to TRUE --- I'm hoping to get Teodor to handle pushing that control down to the opclass consistent() functions. The planner no longer pays any attention to amopreqcheck, and that catalog column will go away in due course.
* Teach ANALYZE to distinguish dead and in-doubt tuples, which it formerlyTom Lane2008-04-03
| | | | | | | | | | | | | | | classed all as "dead"; also get it to count DEAD item pointers as dead rows, instead of ignoring them as before. Also improve matters so that tuples previously inserted or deleted by our own transaction are handled nicely: the stats collector's live-tuple and dead-tuple counts will end up correct after our transaction ends, regardless of whether we end in commit or abort. While there's more work that could be done to improve the counting of in-doubt tuples in both VACUUM and ANALYZE, this commit is enough to alleviate some known bad behaviors in 8.3; and the other stuff that's been discussed seems like research projects anyway. Pavan Deolasee and Tom Lane
* Revert my bad decision of about a year ago to make PortalDefineQueryTom Lane2008-04-02
| | | | | | | | | | | | | | responsible for copying the query string into the new Portal. Such copying is unnecessary in the common code path through exec_simple_query, and in this case it can be enormously expensive because the string might contain a large number of individual commands; we were copying the entire, long string for each command, resulting in O(N^2) behavior for N commands. (This is the cause of bug #4079.) A second problem with it is that PortalDefineQuery really can't risk error, because if it elog's before having set up the Portal, we will leak the plancache refcount that the caller is trying to hand off to the portal. So go back to the design in which the caller is responsible for making sure everything is copied into the portal if necessary.
* Fix my brain fade in TRUNCATE triggers patch: can't release relcache refcountsTom Lane2008-03-31
| | | | | | while EState still contains pointers to those relations. Exposed by the CLOBBER_CACHE_ALWAYS tests that buildfarm member jaguar is running (I knew those cycles would pay off...)
* Support statement-level ON TRUNCATE triggers. Simon RiggsTom Lane2008-03-28
|
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-06 02:33:31 +0000