- 22 10月, 2010 1 次提交
-
-
由 Tom Lane 提交于
This patch eliminates various bizarre behaviors caused by sloppy thinking about the difference between a domain type and its underlying array type. In particular, the operation of updating one element of such an array has to be considered as yielding a value of the underlying array type, *not* a value of the domain, because there's no assurance that the domain's CHECK constraints are still satisfied. If we're intending to store the result back into a domain column, we have to re-cast to the domain type so that constraints are re-checked. For similar reasons, such a domain can't be blindly matched to an ANYARRAY polymorphic parameter, because the polymorphic function is likely to apply array-ish operations that could invalidate the domain constraints. For the moment, we just forbid such matching. We might later wish to insert an automatic downcast to the underlying array type, but such a change should also change matching of domains to ANYELEMENT for consistency. To ensure that all such logic is rechecked, this patch removes the original hack of setting a domain's pg_type.typelem field to match its base type; the typelem will always be zero instead. In those places where it's really okay to look through the domain type with no other logic changes, use the newly added get_base_element_type function in place of get_element_type. catversion bumped due to change in pg_type contents. Per bug #5717 from Richard Huxton and subsequent discussion.
-
- 21 10月, 2010 4 次提交
-
-
由 Tom Lane 提交于
-
由 Bruce Momjian 提交于
-
由 Heikki Linnakangas 提交于
following NULL check was never reached. This problem was found by Coccinelle (null_ref.cocci from coccicheck). Marti Raudsepp
-
由 Tom Lane 提交于
outside a transaction. This repairs brain fade in my patch of 2009-08-30: the reason we had been storing oldest-database name, not OID, in ShmemVariableCache was of course to avoid having to do a catalog lookup at times when it might be unsafe. This error explains why Aleksandr Dushein is having trouble getting out of an XID wraparound state in bug #5718, though not how he got into that state in the first place. I suspect pg_upgrade is at fault there.
-
- 20 10月, 2010 13 次提交
-
-
由 Alvaro Herrera 提交于
This call was present in the aboriginal code from Berkeley, and has never been touched; it may very well be that it was there to mask effects of bugs in other places and it may no longer be necessary. The removal has been foreseen in a code comment since 2007; this seems to be a good time to test this hypothesis.
-
由 Tom Lane 提交于
The trick is to not try to build executables directly from .c files, but to always build the intermediate .o files. For obscure reasons, Darwin's version of gcc will leave debug cruft behind in the first case but not the second. Per complaint from Robert Haas.
-
由 Robert Haas 提交于
-
由 Robert Haas 提交于
Jan Otto, reviewed by Peter Geoghegan
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Tom Lane 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
pg_upgrade slowness for 150k tables.
-
由 Bruce Momjian 提交于
scandir() with a pattern for every table. Optimization after report of pg_upgrade slowness with 150k tables.
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
than packing everything into 'ctx' and passing that to every function.
-
由 Tom Lane 提交于
A couple of places in the planner need to generate whole-row Vars, and were cutting corners by setting vartype = RECORDOID in the Vars, even in cases where there's an identifiable named composite type for the RTE being referenced. While we mostly got away with this, it failed when there was also a parser-generated whole-row reference to the same RTE, because the two Vars weren't equal() due to the difference in vartype. Fix by providing a subroutine the planner can call to generate whole-row Vars the same way the parser does. Per bug #5716 from Andrew Tipton. Back-patch to 9.0 where one of the bogus calls was introduced (the other one is new in HEAD).
-
- 19 10月, 2010 9 次提交
-
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
Backpatch to 9.0.X.
-
由 Bruce Momjian 提交于
recent wal_sync_method doc paragraph to be clearer.
-
由 Robert Haas 提交于
Alexander Korotkov, heavily revised by me.
-
由 Robert Haas 提交于
Report and diagnosis by Peter Eisentraut.
-
由 Bruce Momjian 提交于
Backpatch to 9.0.X.
-
由 Peter Eisentraut 提交于
-
由 Bruce Momjian 提交于
be empty. Because of binary migration usage, it might not be empty.
-
由 Robert Haas 提交于
Peter Eisentraut's recent patch to allow host names in pg_hba.conf changed the contents of pg_hba.conf.sample Fujii Masao
-
- 18 10月, 2010 2 次提交
-
-
由 Tom Lane 提交于
The GIN code has absolutely no business exporting GIN-specific functions with names as generic as compareItemPointers() or newScanKey(); that's just trouble waiting to happen. I got annoyed about this again just now and decided to fix it. This commit ensures that all global symbols defined in access/gin/ have names including "gin" or "Gin". There were a couple of cases, like names involving "PostingItem", where arguably the names were already sufficiently nongeneric; but I figured as long as I was risking creating merge problems for unapplied GIN patches I might as well impose a uniform policy. I didn't touch any static symbol names. There might be some places where it'd be appropriate to rename some static functions to match siblings that are exported, but I'll leave that for another time.
-
由 Tom Lane 提交于
The better estimate requires more statistics than we previously stored: in particular, counts of "entry" versus "data" pages within the index, as well as knowledge of the number of distinct key values. We collect this information during initial index build and update it during VACUUM, storing the info in new fields on the index metapage. No initdb is required because these fields will read as zeroes in a pre-existing index, and the new gincostestimate code is coded to behave (reasonably) sanely if they are zeroes. Teodor Sigaev, reviewed by Jan Urbanski, Tom Lane, and Itagaki Takahiro.
-
- 17 10月, 2010 1 次提交
-
-
由 Magnus Hagander 提交于
Look only at the non-localized part of the output from "vcbuild /?", which is used to determine the version of Visual Studio in use. Different languages seem to localize different amounts of the string, but we assume the part "Microsoft Visual C++" won't be modified.
-
- 16 10月, 2010 7 次提交
-
-
由 Tom Lane 提交于
-
由 Alvaro Herrera 提交于
a corresponding "to" character. Author: Josh Kupershmidt
-
由 Tom Lane 提交于
This is not the hoped-for facility of using INSERT/UPDATE/DELETE inside a WITH, but rather the other way around. It seems useful in its own right anyway. Note: catversion bumped because, although the contents of stored rules might look compatible, there's actually a subtle semantic change. A single Query containing a WITH and INSERT...VALUES now represents writing the WITH before the INSERT, not before the VALUES. While it's not clear that that matters to anyone, it seems like a good idea to have it cited in the git history for catversion.h. Original patch by Marko Tiikkaja, with updating and cleanup by Hitoshi Harada.
-
由 Peter Eisentraut 提交于
Peter Eisentraut, reviewed by KaiGai Kohei and Tom Lane
-
由 Peter Eisentraut 提交于
-
由 Tom Lane 提交于
I also rearranged the order of the sections to match the logical order of processing steps: the distinct-elimination implied by SELECT DISTINCT happens before, not after, any UNION/INTERSECT/EXCEPT combination. Per a suggestion from Hitoshi Harada.
-
由 Alvaro Herrera 提交于
Author: Quan Zongliang Documentation updates by David Fetter
-
- 15 10月, 2010 3 次提交
-
-
由 Magnus Hagander 提交于
Corrupt RADIUS responses were treated as errors and not ignored (which the RFC2865 states they should be). This meant that a user with unfiltered access to the network of the PostgreSQL or RADIUS server could send a spoofed RADIUS response to the PostgreSQL server causing it to reject a valid login, provided the attacker could also guess (or brute-force) the correct port number. Fix is to simply retry the receive in a loop until the timeout has expired or a valid (signed by the correct RADIUS server) packet arrives. Reported by Alan DeKok in bug #5687.
-
由 Simon Riggs 提交于
Error pointed out by Fujii Masao, though not his patch.
-
由 Bruce Momjian 提交于
* Microsoft reports it is related to mutex failure: * http://archives.postgresql.org/pgsql-hackers/2010-09/msg00790.php
-