- 13 2月, 2010 6 次提交
-
-
由 Simon Riggs 提交于
resolution during Hot Standby. Page reuse interlock requested by Tom. Analysis and patch by me.
-
由 Tom Lane 提交于
before we start analyzing the parent statement. This is to make it more clear that the WITH isn't affected by anything in the parent. I don't believe there's any actual bug here, because the stuff that was being done before WITH didn't affect subqueries; but it's certainly a potential for error (and apparently misled Marko into committing some real errors...).
-
由 Andrew Dunstan 提交于
-
由 Tom Lane 提交于
that happens to be composite itself. Per bug #5314 from Oleg Serov. Backpatch to 8.0 --- 7.4 has got too many other shortcomings in composite-type support to make this worth worrying about in that branch.
-
由 Andrew Dunstan 提交于
Add plperl.on_plperl_init and plperl.on_plperlu_init settings for language-specific startup. Rename recently added plperl.on_perl_init to plperl.on_init. Also, code cleanup for utf8 hack. Patch from Tim Bunce, reviewed by Alex Hunsaker.
-
由 Tom Lane 提交于
This patch allows the frame to start from CURRENT ROW (in either RANGE or ROWS mode), and it also adds support for ROWS n PRECEDING and ROWS n FOLLOWING start and end points. (RANGE value PRECEDING/FOLLOWING isn't there yet --- the grammar works, but that's all.) Hitoshi Harada, reviewed by Pavel Stehule
-
- 12 2月, 2010 8 次提交
-
-
由 Heikki Linnakangas 提交于
messages printed at startup. As pointed out by Simon Riggs.
-
由 Heikki Linnakangas 提交于
echo all the recovery.conf options. Don't emit the "initializing recovery connections" message, which doesn't mean anything to a user. Remove the "starting archive recovery" message and replace the "automatic recovery in progress" message with a more informative message saying whether the server is doing PITR, normal archive recovery, or standby mode.
-
由 Heikki Linnakangas 提交于
needs to be done, but it's a step forward..
-
由 Heikki Linnakangas 提交于
connection.
-
由 Heikki Linnakangas 提交于
a partial WAL file, assume it's because the file is just being copied to the archive and treat it the same as "file not found" in standby mode. pg_standby has a similar check, so it seems reasonable to have the same level of protection in the built-in standby mode.
-
由 Andrew Dunstan 提交于
-
由 Tom Lane 提交于
-
由 Simon Riggs 提交于
into code recently patched by Andres Freund, so quickly fixed by him when bug report from Tatsuo Ishii arrived.
-
- 11 2月, 2010 1 次提交
-
-
由 Teodor Sigaev 提交于
several places, but for now only GIN uses it during index creation. Using self-balanced tree greatly speeds up index creation in corner cases with preordered data.
-
- 10 2月, 2010 7 次提交
-
-
由 Heikki Linnakangas 提交于
restoring from archive, the last WAL segment is not necessarily open at the end of recovery. Fix assertion that assumed that. Fujii Masao, fixing the assertion failure reported by Martin Pihlak.
-
由 Tom Lane 提交于
The previous coding missed a bet by sometimes picking the "sorted" path from query_planner even though hashing would be preferable. To fix, we have to be willing to make the choice sooner. This contorts things a little bit, but I thought of a factorization that makes it not too awful.
-
由 Tom Lane 提交于
Move rd_targblock, rd_fsm_nblocks, and rd_vm_nblocks from relcache to the smgr relation entries, so that they will get reset to InvalidBlockNumber whenever an smgr-level flush happens. Because we now send smgr invalidation messages immediately (not at end of transaction) when a relation truncation occurs, this ensures that other backends will reset their values before they next access the relation. We no longer need the unreliable assumption that a VACUUM that's doing a truncation will hold its AccessExclusive lock until commit --- in fact, we can intentionally release that lock as soon as we've completed the truncation. This patch therefore reverts (most of) Alvaro's patch of 2009-11-10, as well as my marginal hacking on it yesterday. We can also get rid of assorted no-longer-needed relcache flushes, which are far more expensive than an smgr flush because they kill a lot more state. In passing this patch fixes smgr_redo's failure to perform visibility-map truncation, and cleans up some rather dubious assumptions in freespace.c and visibilitymap.c about when rd_fsm_nblocks and rd_vm_nblocks can be out of date.
-
由 Heikki Linnakangas 提交于
while it's still being used. Backpatch to 8.4, where the fake relcache method was introduced.
-
由 Magnus Hagander 提交于
-
由 Magnus Hagander 提交于
only in the header files and not in any libraries, yet declare it as an extern.
-
由 Heikki Linnakangas 提交于
sections under "High Availability, Load Balancing, and Replication" chapter. Streaming replication chapter needs a lot more work, but this commit just moves things around.
-
- 09 2月, 2010 6 次提交
-
-
由 Michael Meskes 提交于
First try to make this one ecpg regression test work on Windows too. I'm just trying to figure out the minimal amount of defines needed.
-
由 Tom Lane 提交于
-
由 Tom Lane 提交于
truncating the table and transaction commit. This isn't really making it safe, but at least there is no good reason to do free space map cleanup within the risk window. Don't lock out cancel interrupts until we have to, either.
-
由 Tom Lane 提交于
being called as aggregates, and to get the aggregate transition state memory context if needed. Use it instead of poking directly into AggState and WindowAggState in places that shouldn't know so much. We should have done this in 8.4, probably, but better late than never. Revised version of a patch by Hitoshi Harada.
-
由 Heikki Linnakangas 提交于
anymore.
-
由 Tom Lane 提交于
cluster_rel necessarily builds an all-new toast table, so it's useless to then go and VACUUM FULL the toast table.
-
- 08 2月, 2010 9 次提交
-
-
由 Bruce Momjian 提交于
upgrades.
-
由 Bruce Momjian 提交于
standby featureset.
-
由 Heikki Linnakangas 提交于
recovery. It's zeroed out whenever a checkpoint is written, so the only scenario where the removed code did anything is when you kill archive recovery, remove recovery.conf, and start up the server, so that it goes into crash recovery instead. That's a "don't do that" scenario, but it seems better to not clear minRecoveryPoint but instead update it like we do in archive recovery, which is what will now happen.
-
由 Tom Lane 提交于
needed by nothing else. The restructuring I just finished doing on cache management exposed to me how silly this routine was. Its function was to go into the catcache and blow away all entries related to a given relation when there was a relcache flush on that relation. However, there is no point in removing a catcache entry if the catalog row it represents is still valid --- and if it isn't valid, there must have been a catcache entry flush on it, because that's triggered directly by heap_update or heap_delete on the catalog row. So this routine accomplished nothing except to blow away valid cache entries that we'd very likely be wanting in the near future to help reconstruct the relcache entry. Dumb. On top of which, it required a subtle and easy-to-get-wrong attribute in syscache definitions, ie, the column containing the OID of the related relation if any. Removing that is a very useful maintenance simplification.
-
由 Tom Lane 提交于
-
由 Tom Lane 提交于
VACUUM FULL INPLACE), along with a boatload of subsidiary code and complexity. Per discussion, the use case for this method of vacuuming is no longer large enough to justify maintaining it; not to mention that we don't wish to invest the work that would be needed to make it play nicely with Hot Standby. Aside from the code directly related to old-style VACUUM FULL, this commit removes support for certain WAL record types that could only be generated within VACUUM FULL, redirect-pointer removal in heap_page_prune, and nontransactional generation of cache invalidation sinval messages (the last being the sticking point for Hot Standby). We still have to retain all code that copes with finding HEAP_MOVED_OFF and HEAP_MOVED_IN flag bits on existing tuples. This can't be removed as long as we want to support in-place update from pre-9.0 databases.
-
由 Tom Lane 提交于
as per my recent proposal. First, teach IndexBuildHeapScan to not wait for INSERT_IN_PROGRESS or DELETE_IN_PROGRESS tuples to commit unless the index build is checking uniqueness/exclusion constraints. If it isn't, there's no harm in just indexing the in-doubt tuple. Second, modify VACUUM FULL/CLUSTER to suppress reverifying uniqueness/exclusion constraint properties while rebuilding indexes of the target relation. This is reasonable because these commands aren't meant to deal with corrupted-data situations. Constraint properties will still be rechecked when an index is rebuilt by a REINDEX command. This gets us out of the problem that new-style VACUUM FULL would often wait for other transactions while holding exclusive lock on a system catalog, leading to probable deadlock because those other transactions need to look at the catalogs too. Although the real ultimate cause of the problem is a debatable choice to release locks early after modifying system catalogs, changing that choice would require pretty serious analysis and is not something to be undertaken lightly or on a tight schedule. The present patch fixes the problem in a fairly reasonable way and should also improve the speed of VACUUM FULL/CLUSTER a little bit.
-
由 Tom Lane 提交于
platforms. Per buildfarm.
-
由 Tom Lane 提交于
of shared or nailed system catalogs. This has two key benefits: * The new CLUSTER-based VACUUM FULL can be applied safely to all catalogs. * We no longer have to use an unsafe reindex-in-place approach for reindexing shared catalogs. CLUSTER on nailed catalogs now works too, although I left it disabled on shared catalogs because the resulting pg_index.indisclustered update would only be visible in one database. Since reindexing shared system catalogs is now fully transactional and crash-safe, the former special cases in REINDEX behavior have been removed; shared catalogs are treated the same as non-shared. This commit does not do anything about the recently-discussed problem of deadlocks between VACUUM FULL/CLUSTER on a system catalog and other concurrent queries; will address that in a separate patch. As a stopgap, parallel_schedule has been tweaked to run vacuum.sql by itself, to avoid such failures during the regression tests.
-
- 06 2月, 2010 3 次提交
-
-
由 Tom Lane 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
checkpoint has happened, and recommend adjusting checkpoint_timeout to reduce the impact of this.
-