- 24 Jun, 2012 1 commit
-
-
Heikki Linnakangas authored
The comments claimed that wasting the last segment made it easier to do calculations with XLogRecPtrs, because you don't have problems representing last-byte-position-plus-1 that way. In my experience, however, it only made things more complicated, because the there was two ways to represent the boundary at the beginning of a logical log file: logid = n+1 and xrecoff = 0, or as xlogid = n and xrecoff = 4GB - XLOG_SEG_SIZE. Some functions were picky about which representation was used. Also, use a 64-bit segment number instead of the log/seg combination, to point to a certain WAL segment. We assume that all platforms have a working 64-bit integer type nowadays. This is an incompatible change in WAL format, so bumping WAL version number.
-
- 22 Jun, 2012 2 commits
-
-
Robert Haas authored
These days, even a wimpy system can insert 10000 tuples in the blink of an eye, so there's no real need for this much verbosity. Per complaint from Tatsuo Ishii.
-
Robert Haas authored
Also, add some cross-links to the indexing documentation, so it's easier to notice that && and other array operators have index support. Ryan Kelly, edited by me.
-
- 21 Jun, 2012 5 commits
-
-
Peter Eisentraut authored
To avoid divergent names on related pages, avoid ambiguities, and reduce translation work a little.
-
Tom Lane authored
Repeated execution of an uncorrelated ARRAY_SUBLINK sub-select (which I think can only happen if the sub-select is embedded in a larger, correlated subquery) would leak memory for the duration of the query, due to not reclaiming the array generated in the previous execution. Per bug #6698 from Armando Miraglia. Diagnosis and fix idea by Heikki, patch itself by me. This has been like this all along, so back-patch to all supported versions.
-
Alvaro Herrera authored
-
Heikki Linnakangas authored
This speeds up reassigning locks to the parent owner, when the transaction holds a lot of locks, but only a few of them belong to the current resource owner. This is particularly helps pg_dump when dumping a large number of objects. The cache can hold up to 15 locks in each resource owner. After that, the cache is marked as overflowed, and we fall back to the old method of scanning the whole local lock table. The tradeoff here is that the cache has to be scanned whenever a lock is released, so if the cache is too large, lock release becomes more expensive. 15 seems enough to cover pg_dump, and doesn't have much impact on lock release. Jeff Janes, reviewed by Amit Kapila and Heikki Linnakangas.
-
Tom Lane authored
The original coding in ri_triggers.c had partial support for the concept of zero-column foreign key constraints. But this is not defined in the SQL standard, nor was it ever allowed by any other part of Postgres, nor was it very fully implemented even here (eg there was no support for preventing PK-table deletions that would violate the constraint). Doesn't seem very useful to carry 100-plus lines of code for a corner case that no one is interested in making work. Instead, just add a check that the column list read from pg_constraint is non-empty.
-
- 20 Jun, 2012 3 commits
-
-
Tom Lane authored
By my count there are 18 callers of CacheRegisterSyscacheCallback in the core code in HEAD, so we are potentially leaving as few as 2 slots for any add-on code to use (though possibly not all these callers would actually activate in any particular session). That doesn't seem like a lot of headroom, so let's pump it up a little.
-
Tom Lane authored
Extracting data from pg_constraint turned out to take as much as 10% of the runtime in a bulk-update case where the foreign key column wasn't changing, because we did it over again for each tuple. Fix that by maintaining a backend-local cache of the results. This is really a pretty small patch, but converting the trigger functions to work with pointers rather than local struct variables requires a lot of mechanical changes.
-
Tom Lane authored
During an update of a PK row, we can skip firing the RI trigger if any old key value is NULL, because then the row could not have had any matching rows in the FK table. Conversely, during an update of an FK row, the outcome is determined if any new key value is NULL. In either case it becomes unnecessary to compare individual key values. This patch was inspired by discussion of Vik Reykja's patch to use IS NOT DISTINCT semantics for the key comparisons. In the event there is no need for that and so this patch looks nothing like his, but he should still get credit for having re-opened consideration of the trigger skip logic.
-
- 19 Jun, 2012 5 commits
-
-
Tom Lane authored
The option --foreign-keys, used at initialization time, will create foreign key constraints for the columns that represent references to other tables' primary keys. This can help in benchmarking FK performance. Jeff Janes
-
Alvaro Herrera authored
In passing, reword another instance of the same message that was gratuitously different. Author: Josh Kupershmidt after a bug report by Bosco Rama
-
Peter Eisentraut authored
pointed out by Stefan Kaltenbrunner
-
Tom Lane authored
These triggers are identical except for whether ri_Check_Pk_Match is to be called, so factor out the common code to save a couple hundred lines. Also, eliminate null-column checks in ri_Check_Pk_Match, since they're duplicate with the calling functions and require unnecessary complication in its API statement. Simplify the way code is shared between RI_FKey_check_ins and RI_FKey_check_upd, too.
-
Tom Lane authored
I was confused about this, so try to make it clearer for the next person. (This seems like a fairly inefficient way of dealing with a corner case, but I don't have a better idea offhand. Maybe if there were a way to turn off the RI_FKey_keyequal_upd_fk event filter temporarily?)
-
- 18 Jun, 2012 6 commits
-
-
Tom Lane authored
Once upon a time, somebody was worried that cached RI plans wouldn't get remade with new default values after ALTER TABLE ... SET DEFAULT, so they didn't allow caching of plans for ON UPDATE/DELETE SET DEFAULT actions. That time is long gone, though (and even at the time I doubt this was the greatest hazard posed by ALTER TABLE...). So allow these triggers to cache their plans just like the others. The cache_plan argument to ri_PlanCheck is now vestigial, since there are no callers that don't pass "true"; but I left it alone in case there is any future need for it.
-
Tom Lane authored
We really only need the foreign key constraint's OID and the query type code to uniquely identify each plan we are caching for FK checks. The other stuff that was in the struct had no business being used as part of a hash key, and was all just being copied from struct RI_ConstraintInfo anyway. Get rid of the unnecessary fields, and readjust various function APIs to make them use RI_ConstraintInfo not RI_QueryKey as info source. I'd be surprised if this makes any measurable performance difference, but it certainly feels cleaner.
-
Peter Eisentraut authored
-
Tom Lane authored
Now that what we're implementing isn't SQL92, we probably shouldn't cite chapter and verse in that spec anymore. Also fix some comments that talked about MATCH FULL but in fact were in code that's also used for MATCH SIMPLE. No code changes in this commit, just comments.
-
Tom Lane authored
Previously, when executing an ON UPDATE SET NULL or SET DEFAULT action for a multicolumn MATCH SIMPLE foreign key constraint, we would set only those referencing columns corresponding to referenced columns that were changed. This is what the SQL92 standard said to do --- but more recent versions of the standard say that all referencing columns should be set to null or their default values, no matter exactly which referenced columns changed. At least for SET DEFAULT, that is clearly saner behavior. It's somewhat debatable whether it's an improvement for SET NULL, but it appears that other RDBMS systems read the spec this way. So let's do it like that. This is a release-notable behavioral change, although considering that our documentation already implied it was done this way, the lack of complaints suggests few people use such cases.
-
Tom Lane authored
Previously we followed the SQL92 wording, "MATCH <unspecified>", but since SQL99 there's been a less awkward way to refer to the default style. In addition to the code changes, pg_constraint.confmatchtype now stores this match style as 's' (SIMPLE) rather than 'u' (UNSPECIFIED). This doesn't affect pg_dump or psql because they use pg_get_constraintdef() to reconstruct foreign key definitions. But other client-side code might examine that column directly, so this change will have to be marked as an incompatibility in the 9.3 release notes.
-
- 17 Jun, 2012 3 commits
-
-
Peter Eisentraut authored
Before, some places didn't document the short options (-? and -V), some documented both, some documented nothing, and they were listed in various orders. Now this is hopefully more consistent and complete.
-
Tom Lane authored
Formerly, if the system clock went backwards, the stats collector would fail to update the stats file any more until the clock reading again exceeds whatever timestamp was last written into the stats file. Such glitches in the clock's behavior are not terribly unlikely on machines not using NTP. Such a scenario has been observed to cause regression test failures in the buildfarm, and it could have bad effects on the behavior of autovacuum, so it seems prudent to install some defenses. We could directly detect the clock going backwards by adding GetCurrentTimestamp calls in the stats collector's main loop, but that would hurt performance on platforms where GetCurrentTimestamp is expensive. To minimize the performance hit in normal cases, adopt a more complicated scheme wherein backends check for clock skew when reading the stats file, and if they see it, signal the stats collector by sending an extra stats inquiry message. The stats collector does an extra GetCurrentTimestamp only when it receives an inquiry with an apparently out-of-order timestamp. To avoid unnecessary GetCurrentTimestamp calls, expand the inquiry messages to carry the backend's current clock reading as well as its stats cutoff time. The latter, being intentionally slightly in-the-past, would trigger more clock rechecks than we need if it were used for this purpose. We might want to backpatch this change at some point, but let's let it shake out in the buildfarm for awhile first.
-
Magnus Hagander authored
Since this is the easy way of doing it, it should be listed first. All the old information is retained for those who want the more advanced way. Also adds a subheading for compressing logs, that seems to have been missing
-
- 16 Jun, 2012 3 commits
-
-
Bruce Momjian authored
Backpatch to 9.2. Per suggestion from Noah Misch
-
Bruce Momjian authored
-
Bruce Momjian authored
Àlvaro and Noah Misch. Backpatch to 9.2.
-
- 15 Jun, 2012 2 commits
-
-
Bruce Momjian authored
connection failure. Backpatch to 9.2. Per report from Evan D. Hoffman
-
Peter Eisentraut authored
Because permissions are assigned to element types, not array types, complaining about permission denied on an array type would be misleading to users. So adjust the reporting to refer to the element type instead. In order not to duplicate the required logic in two dozen places, refactor the permission denied reporting for types a bit. pointed out by Yeb Havinga during the review of the type privilege feature
-
- 14 Jun, 2012 10 commits
-
-
Peter Eisentraut authored
Even though we can't do much about the case with multiple plurals in one sentence, we can fix the other cases.
-
Robert Haas authored
Gurjeet Singh, with corrections by me.
-
Robert Haas authored
Fujii Masao
-
Robert Haas authored
Darold Gilles, reviewed by Gabriele Bartolini and others, rebased by Marco Nenciarini. Stylistic cleanup and OID fixes by me.
-
Robert Haas authored
There's no need to hold onto the locks until the files are needed, and by doing it this way, we reduce the impact on other backends who may be awaiting locks we hold. Noah Misch
-
Robert Haas authored
When I implemented the ginbuildempty() function as part of implementing unlogged tables, I falsified the note in the header comment for log_newpage. Although we could fix that up by changing the comment, it seems cleaner to add a new function which is specifically intended to handle this case. So do that.
-
Robert Haas authored
Even when allow_system_table_mods is not set, we allow creation of any type of SQL object in pg_catalog, except for relations. And you can get relations into pg_catalog, too, by initially creating them in some other schema and then moving them with ALTER .. SET SCHEMA. So this restriction, which prevents relations (only) from being created in pg_catalog directly, is fairly pointless. If we need a safety mechanism for this, it should be placed further upstream, so that it affects all SQL objects uniformly, and picks up both CREATE and SET SCHEMA. For now, just rip it out, per discussion with Tom Lane.
-
Robert Haas authored
This may have been important at some point in the past, but it no longer does anything useful. Review by Tom Lane.
-
Robert Haas authored
Alastair Turner, per suggestion from Bruce Momjian.
-
Tom Lane authored
-