aboutsummaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAge
...
* In psql, show view definition only with \d+, not with \dPeter Eisentraut2009-11-03
| | | | | The rationale is that view definitions tend to be long and obscure the main information about the view.
* Fix obscure segfault condition in PL/PythonPeter Eisentraut2009-11-03
| | | | | | | | | | | | | | | In PLy_output(), when the elog() call in the TRY branch throws an exception (this can happen when a statement timeout kicks in, for example), the PyErr_SetString() call in the CATCH branch can cause a segfault, because the Py_XDECREF(so) call before it releases memory that is still used by the sv variable that PyErr_SetString() uses as argument, because sv points into memory owned by so. Backpatched back to 8.0, where this code was introduced. I also threw in a couple of volatile declarations for variables that are used before and after the TRY. I don't think they caused the crash that I observed, but they could become issues.
* Dept of second thoughts: after studying index_getnext() a bit more I realizeTom Lane2009-11-01
| | | | | | that it can scribble on scan->xs_ctup.t_self while following HOT chains, so we can't rely on that to stay valid between hashgettuple() calls. Introduce a private variable in HashScanOpaque, instead.
* Fix two serious bugs introduced into hash indexes by the 8.4 patch that madeTom Lane2009-11-01
| | | | | | | | | | | | | | | | | | | | | | | | hash indexes keep entries sorted by hash value. First, the original plans for concurrency assumed that insertions would happen only at the end of a page, which is no longer true; this could cause scans to transiently fail to find index entries in the presence of concurrent insertions. We can compensate by teaching scans to re-find their position after re-acquiring read locks. Second, neither the bucket split nor the bucket compaction logic had been fixed to preserve hashvalue ordering, so application of either of those processes could lead to permanent corruption of an index, in the sense that searches might fail to find entries that are present. This patch fixes the split and compaction logic to preserve hashvalue ordering, but it cannot do anything about pre-existing corruption. We will need to recommend reindexing all hash indexes in the 8.4.2 release notes. To buy back the performance loss hereby induced in split and compaction, fix them to use PageIndexMultiDelete instead of retail PageIndexDelete operations. We might later want to do something with qsort'ing the page contents rather than doing a binary search for each insertion, but that seemed more invasive than I cared to risk in a back-patch. Per bug #5157 from Jeff Janes and subsequent investigation.
* Ensure the previous Perl interpreter selection is restored upon exit fromTom Lane2009-10-31
| | | | | plperl_call_handler, in both the normal and error-exit paths. Per report from Alexey Klyukin.
* Implement parser hooks for processing ColumnRef and ParamRef nodes, as per myTom Lane2009-10-31
| | | | | | | | | | | | | recent proposal. As proof of concept, remove knowledge of Params from the core parser, arranging for them to be handled entirely by parser hook functions. It turns out we need an additional hook for that --- I had forgotten about the code that handles inferring a parameter's type from context. This is a preliminary step towards letting plpgsql handle its variables through parser hooks. Additional work remains to be done to expose the facility through SPI, but I think this is all the changes needed in the core parser.
* Make the overflow guards in ExecChooseHashTableSize be more protective.Tom Lane2009-10-30
| | | | | | | | | | | | | | | The original coding ensured nbuckets and nbatch didn't exceed INT_MAX, which while not insane on its own terms did nothing to protect subsequent code like "palloc(nbatch * sizeof(BufFile *))". Since enormous join size estimates might well be planner error rather than reality, it seems best to constrain the initial sizes to be not more than work_mem/sizeof(pointer), thus ensuring the allocated arrays don't exceed work_mem. We will allow nbatch to get bigger than that during subsequent ExecHashIncreaseNumBatches calls, but we should still guard against integer overflow in those palloc requests. Per bug #5145 from Bernt Marius Johnsen. Although the given test case only seems to fail back to 8.2, previous releases have variants of this issue, so patch all supported branches.
* Un-break EXPLAIN for Append plans. I messed this up a few days ago whileTom Lane2009-10-28
| | | | | | adding the ModifyTable node type --- I had been thinking ModifyTable should replace Append as a special case in push_plan(), but actually both of them have to be special-cased.
* Fix \df to re-allow regexp special characters in the function name pattern.Tom Lane2009-10-28
| | | | | | This has always worked, up until somebody's thinko here: http://archives.postgresql.org/pgsql-committers/2009-04/msg00233.php Per bug #5143 from Piotr Wolinski.
* Fix AcquireRewriteLocks to be sure that it acquires the right lock strengthTom Lane2009-10-28
| | | | | | when FOR UPDATE is propagated down into a sub-select expanded from a view. Similar bug to parser's isLockedRel issue that I fixed yesterday; likewise seems not quite worth the effort to back-patch.
* When FOR UPDATE/SHARE is used with LIMIT, put the LockRows plan nodeTom Lane2009-10-28
| | | | | | | | | | | | | | | | | underneath the Limit node, not atop it. This fixes the old problem that such a query might unexpectedly return fewer rows than the LIMIT says, due to LockRows discarding updated rows. There is a related problem that LockRows might destroy the sort ordering produced by earlier steps; but fixing that by pushing LockRows below Sort would create serious performance problems that are unjustified in many real-world applications, as well as potential deadlock problems from locking many more rows than expected. Instead, keep the present semantics of applying FOR UPDATE after ORDER BY within a single query level; but allow the user to specify the other way by writing FOR UPDATE in a sub-select. To make that work, track whether FOR UPDATE appeared explicitly in sub-selects or got pushed down from the parent, and don't flatten a sub-select that contained an explicit FOR UPDATE.
* Fix AfterTriggerSaveEvent to use a test and elog, not just Assert, to checkTom Lane2009-10-27
| | | | | | | | | that it's called within an AfterTriggerBeginQuery/AfterTriggerEndQuery pair. The RI cascade triggers suppress that overhead on the assumption that they are always run non-deferred, so it's possible to violate the condition if someone mistakenly changes pg_trigger to mark such a trigger deferred. We don't really care about supporting that, but throwing an error instead of crashing seems desirable. Per report from Marcelo Costa.
* Make FOR UPDATE/SHARE in the primary query not propagate into WITH queries;Tom Lane2009-10-27
| | | | | | | | | | | | | | | | | | | | | | | | for example in WITH w AS (SELECT * FROM foo) SELECT * FROM w, bar ... FOR UPDATE the FOR UPDATE will now affect bar but not foo. This is more useful and consistent than the original 8.4 behavior, which tried to propagate FOR UPDATE into the WITH query but always failed due to assorted implementation restrictions. Even though we are in process of removing those restrictions, it seems correct on philosophical grounds to not let the outer query's FOR UPDATE affect the WITH query. In passing, fix isLockedRel which frequently got things wrong in nested-subquery cases: "FOR UPDATE OF foo" applies to an alias foo in the current query level, not subqueries. This has been broken for a long time, but it doesn't seem worth back-patching further than 8.4 because the actual consequences are minimal. At worst the parser would sometimes get RowShareLock on a relation when it should be AccessShareLock or vice versa. That would only make a difference if someone were using ExclusiveLock concurrently, which no standard operation does, and anyway FOR UPDATE doesn't result in visible changes so it's not clear that the someone would notice any problem. Between that and the fact that FOR UPDATE barely works with subqueries at all in existing releases, I'm not excited about worrying about it.
* Simplify a few makefile rules since install-sh can now install multiplePeter Eisentraut2009-10-26
| | | | files in one run.
* Check errors in for loopPeter Eisentraut2009-10-26
|
* Fix range check in date_recv that tried to limit accepted values to onlyHeikki Linnakangas2009-10-26
| | | | | | | | | | | those accepted by date_in(). I confused julian day numbers and number of days since the postgres epoch 2000-01-01 in the original patch. I just noticed that it's still easy to get such out-of-range values into the database using to_date or +- operators, but this patch doesn't do anything about those functions. Per report from James Pye.
* Re-implement EvalPlanQual processing to improve its performance and eliminateTom Lane2009-10-26
| | | | | | | | | | | | | | | | | | | | | | | | | a lot of strange behaviors that occurred in join cases. We now identify the "current" row for every joined relation in UPDATE, DELETE, and SELECT FOR UPDATE/SHARE queries. If an EvalPlanQual recheck is necessary, we jam the appropriate row into each scan node in the rechecking plan, forcing it to emit only that one row. The former behavior could rescan the whole of each joined relation for each recheck, which was terrible for performance, and what's much worse could result in duplicated output tuples. Also, the original implementation of EvalPlanQual could not re-use the recheck execution tree --- it had to go through a full executor init and shutdown for every row to be tested. To avoid this overhead, I've associated a special runtime Param with each LockRows or ModifyTable plan node, and arranged to make every scan node below such a node depend on that Param. Thus, by signaling a change in that Param, the EPQ machinery can just rescan the already-built test plan. This patch also adds a prohibition on set-returning functions in the targetlist of SELECT FOR UPDATE/SHARE. This is needed to avoid the duplicate-output-tuple problem. It seems fairly reasonable since the other restrictions on SELECT FOR UPDATE are meant to ensure that there is a unique correspondence between source tuples and result tuples, which an output SRF destroys as much as anything else does.
* When querying a table with child tables, do not check permissions on thePeter Eisentraut2009-10-23
| | | | | child tables. This was found to be useless and confusing in virtually all cases, and also contrary to the SQL standard.
* Remove regex_flavor GUC, so that regular expressions are always "advanced"Tom Lane2009-10-21
| | | | | | | | | style by default. Per discussion, there seems to be hardly anything that really relies on being able to change the regex flavor, so the ability to select it via embedded options ought to be enough for any stragglers. Also, if we didn't remove the GUC, we'd really be morally obligated to mark the regex functions non-immutable, which'd possibly create performance issues.
* Remove add_missing_from GUC and associated parser support for "implicit RTEs".Tom Lane2009-10-21
| | | | | | Per recent discussion, add_missing_from has been deprecated for long enough to consider removing, and it's getting in the way of planned parser refactoring. The system now always behaves as though add_missing_from were OFF.
* Translations update for 8.5alpha2Peter Eisentraut2009-10-20
|
* Update translation updating procedure. This pertains to some changes IPeter Eisentraut2009-10-20
| | | | made to automatically exclude translations below the 80% minimum.
* Fix typo in previous release as reported by Itagaki Takahiro, but missedMagnus Hagander2009-10-17
| | | | by me.
* Write to the Windows eventlog in UTF16, converting the message encodingMagnus Hagander2009-10-17
| | | | | | as necessary. Itagaki Takahiro with some changes from me
* Rewrite pam_passwd_conv_proc to be more robust: avoid assuming that theTom Lane2009-10-16
| | | | | | | | | | | | | | pam_message array contains exactly one PAM_PROMPT_ECHO_OFF message. Instead, deal with however many messages there are, and don't throw error for PAM_ERROR_MSG and PAM_TEXT_INFO messages. This logic is borrowed from openssh 5.2p1, which hopefully has seen more real-world PAM usage than we have. Per bug #5121 from Ryan Douglas, which turned out to be caused by the conv_proc being called with zero messages. Apparently that is normal behavior given the combination of Linux pam_krb5 with MS Active Directory as the domain controller. Patch all the way back, since this code has been essentially untouched since 7.4. (Surprising we've not heard complaints before.)
* FREEZE and VERBOSE options were in wrong order in the VACUUM command thatHeikki Linnakangas2009-10-16
| | | | vacuumdb produces. Per report by Thom Brown.
* First committed version of plpython_unicode_0.out did not actually contain theTom Lane2009-10-15
| | | | required \200 bytes. Let's see if this commit works, or if CVS is messing it up.
* Made ECPG more robust against applications freeing strings, based onMichael Meskes2009-10-15
| | | | patch send in by Boszormenyi Zoltan <zb@cybertec.at>.
* Avoid using trivial usernames in foreign_data regression test.Alvaro Herrera2009-10-14
| | | | Author: Martin Pihlak
* Support SQL-compliant triggers on columns, ie fire only if certain columnsTom Lane2009-10-14
| | | | | | | | | | | are named in the UPDATE's SET list. Note: the schema of pg_trigger has not actually changed; we've just started to use a column that was there all along. catversion bumped anyway so that this commit is included in the history of potentially interesting changes to system catalog contents. Itagaki Takahiro
* Rename the new MAX_AUTH_TOKEN_LENGTH #define to PG_MAX_AUTH_MAX_TOKEN_LENGTH,Heikki Linnakangas2009-10-14
| | | | | to make it more obvious that it's a PostgreSQL internal limit, not something that comes from system header files.
* Add alternative expected file for unicode test for client encoding not UTF8Peter Eisentraut2009-10-14
|
* Raise the maximum authentication token (Kerberos ticket) size in GSSAPIHeikki Linnakangas2009-10-14
| | | | | | | | and SSPI athentication methods. While the old 2000 byte limit was more than enough for Unix Kerberos implementations, tickets issued by Windows Domain Controllers can be much larger. Ian Turner
* Add "\pset linestyle ascii/unicode" option to psql, allowing our traditionalTom Lane2009-10-13
| | | | | | | | | | | ASCII-art style of table output to be upgraded to use Unicode box drawing characters if desired. By default, psql will use the Unicode characters whenever client_encoding is UTF8. The patch forces linestyle=ascii in pg_regress usage, ensuring we don't break the regression tests in Unicode locales. Roger Leigh
* Fix ts_stat's failure on empty tsvector.Tom Lane2009-10-13
| | | | | | Also insert a couple of Asserts that check for stack overflow. Bogus coding appears to be new in 8.4 --- older releases had a much simpler algorithm here. Per bug #5111.
* Add new PGC_S_DATABASE_USER enum value to several places missed by my patchAlvaro Herrera2009-10-13
| | | | | | last week. Per note and patch from Jeff Davis.
* Code review for LIKE INCLUDING patch --- clean up some cosmetic and notTom Lane2009-10-13
| | | | so cosmetic stuff.
* Use plurals (TABLES, FUNCTIONS, etc) in ALTER DEFAULT PRIVILEGES. We haveTom Lane2009-10-12
| | | | | the keywords as a consequence of the GRANT ALL patch, so we might as well use them and make the ALTER commands read more naturally.
* Support GRANT/REVOKE ON ALL TABLES/SEQUENCES/FUNCTIONS IN SCHEMA.Tom Lane2009-10-12
| | | | Petr Jelinek
* CREATE LIKE INCLUDING COMMENTS and STORAGE, and INCLUDING ALL shortcut. ↵Andrew Dunstan2009-10-12
| | | | Itagaki Takahiro.
* Move the handling of SELECT FOR UPDATE locking and rechecking out ofTom Lane2009-10-12
| | | | | | | | | | | | | | | | | | | execMain.c and into a new plan node type LockRows. Like the recent change to put table updating into a ModifyTable plan node, this increases planning flexibility by allowing the operations to occur below the top level of the plan tree. It's necessary in any case to restore the previous behavior of having FOR UPDATE locking occur before ModifyTable does. This partially refactors EvalPlanQual to allow multiple rows-under-test to be inserted into the EPQ machinery before starting an EPQ test query. That isn't sufficient to fix EPQ's general bogosity in the face of plans that return multiple rows per test row, though. Since this patch is mostly about getting some plan node infrastructure in place and not about fixing ten-year-old bugs, I will leave EPQ improvements for another day. Another behavioral change that we could now think about is doing FOR UPDATE before LIMIT, but that too seems like it should be treated as a followon patch.
* Improve similar_escape() in two different ways:Tom Lane2009-10-10
| | | | | | | | | | | | | | | | | | | * Stop escaping ? and {. As of SQL:2008, SIMILAR TO is defined to have POSIX-compatible interpretation of ? as well as {m,n} and related constructs, so we should allow these things through to our regex engine. * Escape ^ and $. It appears that our regex engine will treat ^^ at the beginning of the string the same as ^, and similarly for $$ at the end of the string, which meant that SIMILAR TO was effectively ignoring ^ at the start of the pattern and $ at the end. Since these are not supposed to be metacharacters, this is a bug. The second part of this is arguably a back-patchable bug fix, but I'm hesitant to do that because it might break applications that are expecting something like "col SIMILAR TO '^foo$'" to work like a POSIX pattern. Seems safer to only change it at a major version boundary. Per discussion of an example from Doug Gorley.
* Split the processing of INSERT/UPDATE/DELETE operations out of execMain.c.Tom Lane2009-10-10
| | | | | | | | | | They are now handled by a new plan node type called ModifyTable, which is placed at the top of the plan tree. In itself this change doesn't do much, except perhaps make the handling of RETURNING lists and inherited UPDATEs a tad less klugy. But it is necessary preparation for the intended extension of allowing RETURNING queries inside WITH. Marko Tiikkaja
* Use pg_get_triggerdef in pg_dumpPeter Eisentraut2009-10-09
| | | | | | | | | | | Add a variant of pg_get_triggerdef with a second argument "pretty" that causes the output to be formatted in the way pg_dump used to do. Use this variant in pg_dump with server versions >= 8.5. This insulates pg_dump from most future trigger feature additions, such as the upcoming column triggers patch. Author: Itagaki Takahiro <itagaki.takahiro@oss.ntt.co.jp>
* Remove very ancient tuple-counting infrastructure (IncrRetrieved() andTom Lane2009-10-08
| | | | | | | | | friends). This code has all been ifdef'd out for many years, and doesn't seem to have any prospect of becoming any more useful in the future. EXPLAIN ANALYZE is what people use in practice, and I think if we did want process-wide counters we'd be more likely to put in dtrace events for that than try to resurrect this code. Get rid of it so as to have one less detail to worry about while refactoring execMain.c.
* Add the new psql command \drds to the psql docs, help and tab completion.Alvaro Herrera2009-10-08
| | | | | I also thank Bernd Helmle for the documentation help on the previous settings patch, which I forgot on the commit message.
* Fix off-by-one bug in bitncmp(): When comparing a number of bits divisible byHeikki Linnakangas2009-10-08
| | | | | | 8, bitncmp() may dereference a pointer one byte out of bounds. Chris Mikkelson (bug #5101)
* Support use of function argument names to identify which actual argumentsTom Lane2009-10-08
| | | | | | | match which function parameters. The syntax uses AS, for example funcname(value AS arg1, anothervalue AS arg2) Pavel Stehule
* Make it possibly to specify GUC params per user and per database.Alvaro Herrera2009-10-07
| | | | | | | | | | | | | | Create a new catalog pg_db_role_setting where they are now stored, and better encapsulate the code that deals with settings into its realm. The old datconfig and rolconfig columns are removed. psql has gained a \drds command to display the settings. Backwards compatibility warning: while the backwards-compatible system views still have the config columns, they no longer completely represent the configuration for a user or database. Catalog version bumped.
* Fix snapshot management, take two.Alvaro Herrera2009-10-07
| | | | | | | | | | | | | | | | | | | | Partially revert the previous patch I installed and replace it with a more general fix: any time a snapshot is pushed as Active, we need to ensure that it will not be modified in the future. This means that if the same snapshot is used as CurrentSnapshot, it needs to be copied separately. This affects serializable transactions only, because CurrentSnapshot has already been copied by RegisterSnapshot and so PushActiveSnapshot does not think it needs another copy. However, CommandCounterIncrement would modify CurrentSnapshot, whereas ActiveSnapshots must not have their command counters incremented. I say "partially" because the regression test I added for the previous bug has been kept. (This restores 8.3 behavior, because before snapmgr.c existed, any snapshot set as Active was copied.) Per bug report from Stuart Bishop in 6bc73d4c0910042358k3d1adff3qa36f8df75198ecea@mail.gmail.com
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-03 21:44:39 +0000