aboutsummaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAge
...
* In libecpg do not set an sqlda field that is 'reserved for future use' unlessMichael Meskes2011-04-25
| | | | we know what should be stored in there.
* Improve cost estimation for aggregates and window functions.Tom Lane2011-04-24
| | | | | | | | | | | | | | | | The previous coding failed to account properly for the costs of evaluating the input expressions of aggregates and window functions, as seen in a recent gripe from Claudio Freire. (I said at the time that it wasn't counting these costs at all; but on closer inspection, it was effectively charging these costs once per output tuple. That is completely wrong for aggregates, and not exactly right for window functions either.) There was also a hard-wired assumption that aggregates and window functions had procost 1.0, which is now fixed to respect the actual cataloged costs. The costing of WindowAgg is still pretty bogus, since it doesn't try to estimate the effects of spilling data to disk, but that seems like a separate issue.
* Improve findoidjoins to cover more cases.Tom Lane2011-04-23
| | | | | | | | | | | Teach the program and script to deal with OID-array referencing columns, which we now have several of. Also, modify the recommended usage process to specify that the program should be run against the regression database rather than template1. This lets it find numerous joins that cannot be found in template1 because the relevant catalogs are entirely empty. Together these changes add seventeen formerly-missed cases to the oidjoins regression test.
* Silence a few compiler warnings from gcc on MinGW.Andrew Dunstan2011-04-23
| | | | | | | Most of these cast DWORD to int or unsigned int for printf type handling. This is safe even on 64 bit architectures because a DWORD is always 32 bits. In one case a variable is initialised to keep the compiler happy.
* Update oidjoins regression test for 9.1 catalog schema additions.Tom Lane2011-04-23
|
* Hash indexes had better pass the index collation to support functions, too.Tom Lane2011-04-23
| | | | | Per experimentation with contrib/citext, whose hash function assumes that it'll be passed a collation.
* Adjust comments about collate.linux.utf8 regression test.Tom Lane2011-04-23
| | | | | | | This test should now work in any database with UTF8 encoding, regardless of the database's default locale. The former restriction was really "doesn't work if default locale is C", and that was because of not handling mbstowcs/wcstombs correctly.
* Fix char2wchar/wchar2char to support collations properly.Tom Lane2011-04-23
| | | | | | | | | | | | | | | | | These functions should take a pg_locale_t, not a collation OID, and should call mbstowcs_l/wcstombs_l where available. Where those functions are not available, temporarily select the correct locale with uselocale(). This change removes the bogus assumption that all locales selectable in a given database have the same wide-character conversion method; in particular, the collate.linux.utf8 regression test now passes with LC_CTYPE=C, so long as the database encoding is UTF8. I decided to move the char2wchar/wchar2char functions out of mbutils.c and into pg_locale.c, because they work on wchar_t not pg_wchar_t and thus don't really belong with the mbutils.c functions. Keeping them where they were would have required importing pg_locale_t into pg_wchar.h somehow, which did not seem like a good plan.
* Make GIN and GIST pass the index collation to all their support functions.Tom Lane2011-04-22
| | | | | | | Experimentation with contrib/btree_gist shows that the majority of the GIST support functions potentially need collation information. Safest policy seems to be to pass it to all of them, instead of making assumptions about which ones could possibly need it.
* Small update to emacs example configurationPeter Eisentraut2011-04-23
| | | | | | Since both tarballs and git now result in a "postgresql" directory rather than a "pgsql" directory, adjust the example configuration to look for the former.
* Add fill-column setting to emacs example configurationsPeter Eisentraut2011-04-23
| | | | This matches the maximum line length that pgindent uses.
* Make a code-cleanup pass over the collations patch.Tom Lane2011-04-22
| | | | | | | This patch is almost entirely cosmetic --- mostly cleaning up a lot of neglected comments, and fixing code layout problems in places where the patch made lines too long and then pgindent did weird things with that. I did find a bug-of-omission in equalTupleDescs().
* Avoid possible divide-by-zero in gincostestimate.Tom Lane2011-04-21
| | | | Per report from Jeff Janes.
* Allow ALTER TYPE .. ADD ATTRIBUTE .. CASCADE to recurse to descendants.Robert Haas2011-04-20
| | | | | | | Without this, adding an attribute to a typed table with an inheritance child fails, which is surprising. Noah Misch, with minor changes by me.
* Fix use of incorrect constant RemoveRoleFromObjectACL.Robert Haas2011-04-20
| | | | | | | This could cause failures when DROP OWNED BY attempt to remove default privileges on sequences. Back-patching to 9.0. Shigeru Hanada
* Typo fix.Robert Haas2011-04-20
|
* Allow ALTER TABLE name {OF type | NOT OF}.Robert Haas2011-04-20
| | | | | | | | | | | This syntax allows a standalone table to be made into a typed table, or a typed table to be made standalone. This is possibly a mildly useful feature in its own right, but the real motivation for this change is that we need it to make pg_upgrade work with typed tables. This doesn't actually fix that problem, but it's necessary infrastructure. Noah Misch
* Fix bugs in indexing of in-doubt HOT-updated tuples.Tom Lane2011-04-20
| | | | | | | | | | | | | | | | | | | | | | | | | If we find a DELETE_IN_PROGRESS HOT-updated tuple, it is impossible to know whether to index it or not except by waiting to see if the deleting transaction commits. If it doesn't, the tuple might again be LIVE, meaning we have to index it. So wait and recheck in that case. Also, we must not rely on ii_BrokenHotChain to decide that it's possible to omit tuples from the index. That could result in omitting tuples that we need, particularly in view of yesterday's fixes to not necessarily set indcheckxmin (but it's broken even without that, as per my analysis today). Since this is just an extremely marginal performance optimization, dropping the test shouldn't hurt. These cases are only expected to happen in system catalogs (they're possible there due to early release of RowExclusiveLock in most catalog-update code paths). Since reindexing of a system catalog isn't a particularly performance-critical operation anyway, there's no real need to be concerned about possible performance degradation from these changes. The worst aspects of this bug were introduced in 9.0 --- 8.x will always wait out a DELETE_IN_PROGRESS tuple. But I think dropping index entries on the strength of ii_BrokenHotChain is dangerous even without that, so back-patch removal of that optimization to 8.3 and 8.4.
* Set indcheckxmin true when REINDEX fixes an invalid or not-ready index.Tom Lane2011-04-20
| | | | | | | | | | | Per comment from Greg Stark, it's less clear that HOT chains don't conflict with the index than it would be for a valid index. So, let's preserve the former behavior that indcheckxmin does get set when there are potentially-broken HOT chains in this case. This change does not cause any pg_index update that wouldn't have happened anyway, so we're not re-introducing the previous bug with pg_index updates, and surely the case is not significant from a performance standpoint; so let's be as conservative as possible.
* Make plan_cluster_use_sort cope with no IndexOptInfo for the target index.Tom Lane2011-04-20
| | | | | | | | | The original coding assumed that such a case represents caller error, but actually get_relation_info will omit generating an IndexOptInfo for any index it thinks is unsafe to use. Therefore, handle this case by returning "true" to indicate that a seqscan-and-sort is the preferred way to implement the CLUSTER operation. New bug in 9.1, no backpatch needed. Per bug #5985 from Daniel Grace.
* Fix PL/Python traceback for error in separate filePeter Eisentraut2011-04-20
| | | | | | | | | | | | It assumed that the lineno from the traceback always refers to the PL/Python function. If you created a PL/Python function that imports some code, runs it, and that code raises an exception, PLy_traceback would get utterly confused. Now we look at the file name reported with the traceback and only print the source line if it came from the PL/Python function. Jan Urbański
* Quotes in strings injected into bki file need to escaped. In particular,Heikki Linnakangas2011-04-20
| | | | | | | | | "People's Republic of China" locale on Windows was causing initdb to fail. This fixes bug #5818 reported by yulei. On master, this makes the mapping of "People's Republic of China" to just "China" obsolete. In 9.0 and 8.4, just fix the escaping. Earlier versions didn't have locale names in bki file.
* Avoid changing an index's indcheckxmin horizon during REINDEX.Tom Lane2011-04-19
| | | | | | | | | | | | | | | | | | | | There can never be a need to push the indcheckxmin horizon forward, since any HOT chains that are actually broken with respect to the index must pre-date its original creation. So we can just avoid changing pg_index altogether during a REINDEX operation. This offers a cleaner solution than my previous patch for the problem found a few days ago that we mustn't try to update pg_index while we are reindexing it. System catalog indexes will always be created with indcheckxmin = false during initdb, and with this modified code we should never try to change their pg_index entries. This avoids special-casing system catalogs as the former patch did, and should provide a performance benefit for many cases where REINDEX formerly caused an index to be considered unusable for a short time. Back-patch to 8.3 to cover all versions containing HOT. Note that this patch changes the API for index_build(), but I believe it is unlikely that any add-on code is calling that directly.
* Revert "Prevent incorrect updates of pg_index while reindexing pg_index itself."Tom Lane2011-04-19
| | | | | This reverts commit 4b6106ccfea21e86943f881edcf3cfc03661a415 of 2011-04-15. There's a better way to do it, which will follow shortly.
* Refix the unaccent regression test on MSVC properlyPeter Eisentraut2011-04-19
| | | | | | ... for some value of "properly". Instead of overriding REGRESS_OPTS, set the variables ENCODING and NO_LOCALE, which is more expressive and allows overriding by the user. Fix vcregress.pl to handle that.
* Treat config.pl as optional in vcregress.plPeter Eisentraut2011-04-19
| | | | This is how build.pl treats it and how it's documented.
* Fix typoPeter Eisentraut2011-04-19
|
* Add gitignore entries for Windows MSVC buildsPeter Eisentraut2011-04-19
|
* Refrain from canonicalizing a client_encoding setting of "UNICODE".Tom Lane2011-04-19
| | | | | | | | | While "UTF8" is the correct name for this encoding, existing JDBC drivers expect that if they send "UNICODE" it will read back the same way; they fail with an opaque "Protocol error" complaint if not. This will be fixed in the 9.1 drivers, but until older drivers are no longer in use in the wild, we'd better leave "UNICODE" alone. Continue to canonicalize all other inputs. Per report from Steve Singer and subsequent discussion.
* Silence compiler warning about casting HANDLE to long on WIN64.Andrew Dunstan2011-04-19
|
* Silence compiler warning about unused variable on Windows.Heikki Linnakangas2011-04-19
|
* Fix handling of collations in multi-row VALUES constructs.Tom Lane2011-04-18
| | | | | | | | | Per spec we ought to apply select_common_collation() across the expressions in each column of the VALUES table. The original coding was just taking the first row and assuming it was representative. This patch adds a field to struct RangeTblEntry to carry the resolved collations, so initdb is forced for changes in stored rule representation.
* Only allow typed tables to hang off composite types, not e.g. tables.Robert Haas2011-04-18
| | | | | | | | | This also ensures that we take a relation lock on the composite type when creating a typed table, which is necessary to prevent the composite type and the typed table from getting out of step in the face of concurrent DDL. Noah Misch, with some changes.
* recoveryStopsHere() must check the resource manager ID.Robert Haas2011-04-18
| | | | | | | | | | Before commit c016ce728139be95bb0dc7c4e5640507334c2339, this wasn't needed, but now that multiple resource manager IDs can percolate down through here, we have to make sure we know which one we've got. Otherwise, we can confuse (for example) an XLOG_XACT_COMMIT record with an XLOG_CHECKPOINT_SHUTDOWN record. Review by Jaime Casanova
* Fix assorted infelicities in collation handling in psql's describe.c.Tom Lane2011-04-17
| | | | | | | | | | | | | In \d, be more careful to print collation only if it's not the default for the column's data type. Avoid assuming that the name "default" is magic. Fix \d on a composite type so that it will print per-column collations. It's no longer the case that a composite type cannot have modifiers. (In consequence, the expected outputs for composite-type regression tests change.) Fix \dD so that it will print collation for a domain, again only if it's not the same as the base type's collation.
* Fix pg_dump to handle collations applied to columns of composite types.Tom Lane2011-04-17
| | | | | CREATE TYPE and ALTER TYPE ADD ATTRIBUTE handle this, so I suppose it's an intended feature, but pg_dump didn't know about it.
* Add check for matching column collations in ALTER TABLE ... INHERIT.Tom Lane2011-04-17
| | | | | | | The other DDL operations that create an inheritance relationship were checking for collation match already, but this one got missed. Also fix comments that failed to mention collation checks.
* Support a COLLATE clause in plpgsql variable declarations.Tom Lane2011-04-17
| | | | | | | This allows the usual rules for assigning a collation to a local variable to be overridden. Per discussion, it seems appropriate to support this rather than forcing all local variables to have the argument-derived collation.
* foreach() and list_delete() don't mix.Tom Lane2011-04-17
| | | | | | | | | | | Fix crash when releasing duplicate entries in the encoding conversion cache list, caused by releasing the current entry of the list being chased by foreach(). We have a standard idiom for handling such cases, but this loop wasn't using it. This got broken in my recent rewrite of GUC assign hooks. Not sure how I missed this when testing the modified code, but I did. Per report from Peter.
* Add an Assert that indexam.c isn't used on an index awaiting reindexing.Tom Lane2011-04-16
| | | | | | | This might have caught the recent embarrassment over trying to modify pg_index while its indexes were being rebuilt. Noah Misch
* Simplify reindex_relation's API.Tom Lane2011-04-16
| | | | | | | For what seem entirely historical reasons, a bitmask "flags" argument was recently added to reindex_relation without subsuming its existing boolean argument into that bitmask. This seems a bit bizarre, so fold them together.
* Clean up collation processing in prepunion.c.Tom Lane2011-04-16
| | | | | | | | | | | | This area was a few bricks shy of a load, and badly under-commented too. We have to ensure that the generated targetlist entries for a set-operation node expose the correct collation for each entry, since higher-level processing expects the tlist to reflect the true ordering of the plan's output. This hackery wouldn't be necessary if SortGroupClause carried collation info ... but making it do so would inject more pain in the parser than would be saved here. Still, we might want to rethink that sometime.
* Set client encoding explicitly in plpython_unicode testPeter Eisentraut2011-04-16
| | | | | This will (hopefully) eliminate the need for the plpython_unicode_0.out expected file.
* Prevent incorrect updates of pg_index while reindexing pg_index itself.Tom Lane2011-04-15
| | | | | | | | | | | | | | | | | | | | The places that attempt to change pg_index.indcheckxmin during a reindexing operation cannot be executed safely if pg_index itself is the subject of the operation. This is the explanation for a couple of recent reports of VACUUM FULL failing with ERROR: duplicate key value violates unique constraint "pg_index_indexrelid_index" DETAIL: Key (indexrelid)=(2678) already exists. However, there isn't any real need to update indcheckxmin in such a situation, if we assume that pg_index can never contain a truly broken HOT chain. This assumption holds if new indexes are never created on it during concurrent operations, which is something we don't consider safe for any system catalog, not just pg_index. Accordingly, modify the code to not manipulate indcheckxmin when reindexing any system catalog. Back-patch to 8.3, where HOT was introduced. The known failure scenarios involve 9.0-style VACUUM FULL, so there might not be any real risk before 9.0, but let's not assume that.
* Suppress unused-function warning on non-WIN32 builds.Tom Lane2011-04-15
|
* Guard against incoming rowcount estimate of NaN in cost_mergejoin().Tom Lane2011-04-15
| | | | | | | | | | Although rowcount estimates really ought not be NaN, a bug elsewhere could perhaps result in that, and that would cause Assert failure in cost_mergejoin, which I believe to be the explanation for bug #5977 from Anton Kuznetsov. Seems like a good idea to expend a couple more cycles to prevent that, even though the real bug is elsewhere. Not back-patching, though, because we don't encourage running production systems with Asserts on.
* setlocale() on Windows doesn't work correctly if the locale name containsHeikki Linnakangas2011-04-15
| | | | | | apostrophes or dots. There isn't much hope of Microsoft fixing it any time soon, it's been like that for ages, so we better work around it. So, map a few common Windows locale names known to cause problems to aliases that work.
* On Windows, if the encoding implied by locale is not allowed as aHeikki Linnakangas2011-04-15
| | | | | | server-encoding, fall back to UTF-8. It happens at least with the Chinese locale, which implies BIG5. This is safe, because on Windows all locales are compatible with UTF-8.
* Reduce the initial size of local lock hash to 16 entries.Heikki Linnakangas2011-04-15
| | | | | | | | | | | The hash table is seq scanned at transaction end, to release all locks, and making the hash table larger than necessary makes that slower. With very simple queries, that overhead can amount to a few percent of the total CPU time used. At the moment, backend startup needs 6 locks, and a simple query with one table and index needs 3 locks. 16 is enough for even quite complicated transactions, and it will grow automatically if it fills up.
* Rename pg_regress option --multibyte to --encodingPeter Eisentraut2011-04-15
| | | | | Also refactor things a little bit so that the same methods for setting test locale and encoding can be used everywhere.
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-04 06:25:09 +0000