- 25 11月, 2011 1 次提交
-
-
由 Robert Haas 提交于
This speeds up snapshot-taking and reduces ProcArrayLock contention. Also, the PGPROC (and PGXACT) structures used by two-phase commit are now allocated as part of the main array, rather than in a separate array, and we keep ProcArray sorted in pointer order. These changes are intended to minimize the number of cache lines that must be pulled in to take a snapshot, and testing shows a substantial increase in performance on both read and write workloads at high concurrencies. Pavan Deolasee, Heikki Linnakangas, Robert Haas
-
- 11 11月, 2011 1 次提交
-
-
由 Robert Haas 提交于
This reverts commit 0180bd61. contrib/userlock is gone, but user-level locking still exists, and is exposed via the pg_advisory* family of functions.
-
- 14 10月, 2011 1 次提交
-
-
由 Bruce Momjian 提交于
in PG 8.2.
-
- 11 10月, 2011 1 次提交
-
-
由 Robert Haas 提交于
I broke this in commit 84e37126. Report and fix by Fujii Masao.
-
- 12 9月, 2011 1 次提交
-
-
由 Peter Eisentraut 提交于
This addresses only those cases that are easy to fix by adding or moving a const qualifier or removing an unnecessary cast. There are many more complicated cases remaining.
-
- 27 8月, 2011 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 23 8月, 2011 1 次提交
-
-
由 Robert Haas 提交于
-
- 05 8月, 2011 1 次提交
-
-
由 Robert Haas 提交于
Instead of entering them on transaction startup, we materialize them only when someone wants to wait, which will occur only during CREATE INDEX CONCURRENTLY. In Hot Standby mode, the startup process must also be able to probe for conflicting VXID locks, but the lock need never be fully materialized, because the startup process does not use the normal lock wait mechanism. Since most VXID locks never need to touch the lock manager partition locks, this can significantly reduce blocking contention on read-heavy workloads. Patch by me. Review by Jeff Davis.
-
- 03 8月, 2011 1 次提交
-
-
由 Tom Lane 提交于
This kluge was inserted in a spot apparently chosen at random: the lock manager's state is not yet fully set up for the wait, and in particular LockWaitCancel hasn't been armed by setting lockAwaited, so the ProcLock will not get cleaned up if the ereport is thrown. This seems to not cause any observable problem in trivial test cases, because LockReleaseAll will silently clean up the debris; but I was able to cause failures with tests involving subtransactions. Fixes breakage induced by commit c85c9414. Back-patch to all affected branches.
-
- 20 7月, 2011 1 次提交
-
-
由 Robert Haas 提交于
1. In GetLockStatusData, avoid initializing instance before we've ensured that the array is large enough. Otherwise, if repalloc moves the block around, we're hosed. 2. Add the word "Relation" to the name of some identifiers, to avoid assuming that the fast-path mechanism will only ever apply to relations (though these particular parts certainly will). Some of the macros could possibly use similar treatment, but the names are getting awfully long already. 3. Add a missing word to comment in AtPrepare_Locks().
-
- 18 7月, 2011 1 次提交
-
-
由 Robert Haas 提交于
When an AccessShareLock, RowShareLock, or RowExclusiveLock is requested on an unshared database relation, and we can verify that no conflicting locks can possibly be present, record the lock in a per-backend queue, stored within the PGPROC, rather than in the primary lock table. This eliminates a great deal of contention on the lock manager LWLocks. This patch also refactors the interface between GetLockStatusData() and pg_lock_status() to be a bit more abstract, so that we don't rely so heavily on the lock manager's internal representation details. The new fast path lock structures don't have a LOCK or PROCLOCK structure to return, so we mustn't depend on that for purposes of listing outstanding locks. Review by Jeff Davis.
-
- 15 4月, 2011 1 次提交
-
-
由 Heikki Linnakangas 提交于
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.
-
- 10 4月, 2011 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 18 2月, 2011 1 次提交
-
-
由 Itagaki Takahiro 提交于
They share the same locking namespace with the existing session-level advisory locks, but they are automatically released at the end of the current transaction and cannot be released explicitly via unlock functions. Marko Tiikkaja, reviewed by me.
-
- 02 1月, 2011 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 29 11月, 2010 1 次提交
-
-
由 Simon Riggs 提交于
removing an infrequently occurring race condition in Hot Standby. An xid must be assigned before a lock appears in shared memory, rather than immediately after, else GetRunningTransactionLocks() may see InvalidTransactionId, causing assertion failures during lock processing on standby. Bug report and diagnosis by Fujii Masao, fix by me.
-
- 21 9月, 2010 1 次提交
-
-
由 Magnus Hagander 提交于
-
- 29 4月, 2010 1 次提交
-
-
由 Tom Lane 提交于
rather than returning NULL for some-but-not-all failures as they used to. Remove now-redundant tests for NULL from call sites. We had to do something about this because many call sites were failing to check for NULL; and changing it like this seems a lot more useful and mistake-proof than adding checks to the call sites without them.
-
- 21 3月, 2010 1 次提交
-
-
由 Peter Eisentraut 提交于
-
- 26 2月, 2010 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 01 2月, 2010 1 次提交
-
-
由 Simon Riggs 提交于
stage of required deadlock detection to allow re-enabling max_standby_delay setting of -1, which is now essential in the absence of improved relation- specific conflict resoluton. Requested by Greg Stark et al.
-
- 30 1月, 2010 1 次提交
-
-
由 Simon Riggs 提交于
executed InHotStandby. Cleaner solution than using malloc or palloc depending upon situation, as proposed by Tom.
-
- 28 1月, 2010 1 次提交
-
-
由 Simon Riggs 提交于
palloc calls. Current code assumed this was already true, so this is a bug fix.
-
- 24 1月, 2010 1 次提交
-
-
由 Simon Riggs 提交于
woken by alarm we send SIGUSR1 to all backends requesting that they check to see if they are blocking Startup process. If so, they throw ERROR/FATAL as for other conflict resolutions. Deadlock stop gap removed. max_standby_delay = -1 option removed to prevent deadlock.
-
- 03 1月, 2010 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 19 12月, 2009 1 次提交
-
-
由 Simon Riggs 提交于
Enabled by recovery_connections = on (default) and forcing archive recovery using a recovery.conf. Recovery processing now emulates the original transactions as they are replayed, providing full locking and MVCC behaviour for read only queries. Recovery must enter consistent state before connections are allowed, so there is a delay, typically short, before connections succeed. Replay of recovering transactions can conflict and in some cases deadlock with queries during recovery; these result in query cancellation after max_standby_delay seconds have expired. Infrastructure changes have minor effects on normal running, though introduce four new types of WAL record. New test mode "make standbycheck" allows regression tests of static command behaviour on a standby server while in recovery. Typical and extreme dynamic behaviours have been checked via code inspection and manual testing. Few port specific behaviours have been utilised, though primary testing has been on Linux only so far. This commit is the basic patch. Additional changes will follow in this release to enhance some aspects of behaviour, notably improved handling of conflicts, deadlock detection and query cancellation. Changes to VACUUM FULL are also required. Simon Riggs, with significant and lengthy review by Heikki Linnakangas, including streamlined redesign of snapshot creation and two-phase commit. Important contributions from Florian Pflug, Mark Kirkwood, Merlin Moncure, Greg Stark, Gianni Ciolli, Gabriele Bartolini, Hannu Krosing, Robert Haas, Tatsuo Ishii, Hiroyuki Yamada plus support and feedback from many other community members.
-
- 11 6月, 2009 1 次提交
-
-
由 Bruce Momjian 提交于
provided by Andrew.
-
- 23 3月, 2009 1 次提交
-
-
由 Tom Lane 提交于
probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
-
- 02 1月, 2009 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 03 11月, 2008 1 次提交
-
-
由 Tom Lane 提交于
allowed different processes to have different addresses for the shmem segment in quite a long time, but there were still a few places left that used the old coding convention. Clean them up to reduce confusion and improve the compiler's ability to detect pointer type mismatches. Kris Jurka
-
- 01 8月, 2008 1 次提交
-
-
由 Alvaro Herrera 提交于
Robert Lor
-
- 18 3月, 2008 1 次提交
-
-
由 Peter Eisentraut 提交于
support DTrace in the future. Switch from using DTRACE_PROBEn macros to the dynamically generated macros. Use "dtrace -h" to create a header file that contains the dynamically generated macros to be used in the source code instead of the DTRACE_PROBEn macros. A dummy header file is generated for builds without DTrace support. Author: Robert Lor <Robert.Lor@sun.com>
-
- 05 3月, 2008 1 次提交
-
-
由 Tom Lane 提交于
temporary table; we can't support that because there's no way to clean up the source backend's internal state if the eventual COMMIT PREPARED is done by another backend. This was checked correctly in 8.1 but I broke it in 8.2 :-(. Patch by Heikki Linnakangas, original trouble report by John Smith.
-
- 03 2月, 2008 1 次提交
-
-
由 Tom Lane 提交于
erroring out of a wait. We can use a PG_TRY block for this, but add a comment explaining why it'd be a bad idea to use it for any other state cleanup. Back-patch to 8.2. Prior releases had the same issue, but only with respect to the process title, which is likely to get reset almost immediately anyway after the transaction aborts, so it seems not worth changing them. In 8.2 and HEAD, the pg_stat_activity "waiting" flag could remain set incorrectly for a long time. Per report from Gurjeet Singh.
-
- 02 1月, 2008 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 16 11月, 2007 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 06 9月, 2007 1 次提交
-
-
由 Tom Lane 提交于
rows will normally never obtain an XID at all. We already did things this way for subtransactions, but this patch extends the concept to top-level transactions. In applications where there are lots of short read-only transactions, this should improve performance noticeably; not so much from removal of the actual XID-assignments, as from reduction of overhead that's driven by the rate of XID consumption. We add a concept of a "virtual transaction ID" so that active transactions can be uniquely identified even if they don't have a regular XID. This is a much lighter-weight concept: uniqueness of VXIDs is only guaranteed over the short term, and no on-disk record is made about them. Florian Pflug, with some editorialization by Tom.
-
- 17 7月, 2007 1 次提交
-
-
由 Tom Lane 提交于
partition locks in reverse order.
-
- 02 2月, 2007 1 次提交
-
-
由 Bruce Momjian 提交于
Standard English uses "may", "can", and "might" in different ways: may - permission, "You may borrow my rake." can - ability, "I can lift that log." might - possibility, "It might rain today." Unfortunately, in conversational English, their use is often mixed, as in, "You may use this variable to do X", when in fact, "can" is a better choice. Similarly, "It may crash" is better stated, "It might crash".
-
- 06 1月, 2007 1 次提交
-
-
由 Bruce Momjian 提交于
back-stamped for this.
-