- 30 8月, 2017 1 次提交
-
-
由 Heikki Linnakangas 提交于
It was getting in the way of backporting commit 9b1b9446f5 from PostgreSQL, which added an '#include "storage/lock.h"' to resowner.h, forming a cycle. The include was only needed for the decalaration of awaitedOwner global variable. Replace "ResourceOwner" with the equivalent "struct ResourceOwnerData *" to avoid it. This revealed a bunch of other files that were relying on resowner.h being indirectly included through lock.h. Include resowner.h directly in those files. The ResPortalIncrement.owner field was not used for anything, so instead of including resowner.h in that file, just remove the field that needed it.
-
- 07 3月, 2017 1 次提交
-
-
由 Ashwin Agrawal 提交于
Originally checkpoint is checking for xid, however, xid is used to control the transaction visibility and it's crucial to clean this xid if process is done with commit and before release locks. However, checkpoint need to wait for the `AtExat_smgr()` to cleanup persistent table information, which happened after release locks, where `xid` is already cleaned. Hence, we use VXID, which doesn't have visibility impact. NOTE: Upstream PostgreSQL commit f21bb9cf for the similar fix.
-
- 02 3月, 2017 1 次提交
-
-
由 Lirong Jian 提交于
-
- 18 8月, 2016 1 次提交
-
-
由 Heikki Linnakangas 提交于
I found these with "callcatcher", written by Caolán McNamara. Many thanks for the tool! See https://www.skynet.ie/~caolan/Packages/callcatcher.html
-
- 27 6月, 2016 1 次提交
-
- 22 2月, 2016 1 次提交
-
-
由 Kenan Yao 提交于
failure fixed) In some error cases, the resource queue lock is not released, hence leading to lock leak and inconsistent resource queue status; this commit overhauls the resource queue locking code to complete the cleanups if error or signal happens during acquiring resource queue lock; meanwhile, some unnecessary code blocks are removed and unreasonable code are fixed to make it easier for reading and understanding;
-
- 06 2月, 2016 1 次提交
-
-
由 Pengzhou Tang 提交于
This reverts commit b46f781f.
-
- 04 2月, 2016 1 次提交
-
-
由 Kenan Yao 提交于
In some error cases, the resource queue lock is not released, hence leading to lock leak and inconsistent resource queue status; this commit overhauls the resource queue locking code to complete the cleanups if error or signal happens during acquiring resource queue lock; meanwhile, some unnecessary code blocks are removed and unreasonable code are fixed to make it easier for reading and understanding;
-
- 28 10月, 2015 1 次提交
-
-
- 16 9月, 2008 1 次提交
-
-
由 Tom Lane 提交于
forestalls potential overflow when the same table (or other object, but usually tables) is accessed by very many successive queries within a single transaction. Per report from Michael Milligan. Back-patch to 8.0, which is as far back as the patch conveniently applies. There have been no reports of overflow in pre-8.3 releases, but clearly the risk existed all along. (Michael's report suggests that 8.3 may consume lock counts faster than prior releases, but with no test case to look at it's hard to be sure about that. Widening the counts seems a good future-proofing measure in any event.)
-
- 09 1月, 2008 1 次提交
-
-
由 Tom Lane 提交于
Also a couple of minor tweaks to try to future-proof the code a bit better against future locktag additions.
-
- 02 1月, 2008 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 16 11月, 2007 2 次提交
-
-
由 Bruce Momjian 提交于
avoid this problem in the future.)
-
由 Bruce Momjian 提交于
-
- 27 10月, 2007 1 次提交
-
-
由 Alvaro Herrera 提交于
to be locking another process (except when it's working to prevent Xid wraparound problems).
-
- 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.
-
- 20 6月, 2007 1 次提交
-
-
由 Tom Lane 提交于
within a signal handler (this might be safe given the relatively narrow code range in which the interrupt is enabled, but it seems awfully risky); do issue more informative log messages that tell what is being waited for and the exact length of the wait; minor other code cleanup. Greg Stark and Tom Lane
-
- 31 5月, 2007 1 次提交
-
-
由 Tom Lane 提交于
-
- 04 3月, 2007 1 次提交
-
-
由 Bruce Momjian 提交于
Simon Riggs
-
- 06 1月, 2007 1 次提交
-
-
由 Bruce Momjian 提交于
back-stamped for this.
-
- 23 11月, 2006 1 次提交
-
-
由 Bruce Momjian 提交于
Walter Cruz
-
- 04 10月, 2006 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 23 9月, 2006 1 次提交
-
-
由 Tom Lane 提交于
backward compatibility for anyone using the old userlock code that's now on pgfoundry --- locks from that code still show as 'userlock'.
-
- 19 9月, 2006 1 次提交
-
-
由 Tom Lane 提交于
contrib functionality. Along the way, remove the USER_LOCKS configuration symbol, since it no longer makes any sense to try to compile that out. No user documentation yet ... mmoncure has promised to write some. Thanks to Abhijit Menon-Sen for creating a first draft to work from.
-
- 28 8月, 2006 1 次提交
-
-
由 Tom Lane 提交于
locks that would conflict with a specified lock request, without actually trying to get that lock. Use this instead of the former ad hoc method of doing the first wait step in CREATE INDEX CONCURRENTLY. Fixes problem with undetected deadlock and in many cases will allow the index creation to proceed sooner than it otherwise could've. Per discussion with Greg Stark.
-
- 01 8月, 2006 1 次提交
-
-
由 Tom Lane 提交于
(table or index) before trying to open its relcache entry. This fixes race conditions in which someone else commits a change to the relation's catalog entries while we are in process of doing relcache load. Problems of that ilk have been reported sporadically for years, but it was not really practical to fix until recently --- for instance, the recent addition of WAL-log support for in-place updates helped. Along the way, remove pg_am.amconcurrent: all AMs are now expected to support concurrent update.
-
- 24 7月, 2006 1 次提交
-
-
由 Tom Lane 提交于
hash tables, instead of the previous kluge involving multiple hash tables. This partially undoes my patch of last December.
-
- 23 7月, 2006 1 次提交
-
-
由 Tom Lane 提交于
partitions, as per discussion. Passes functionality checks, but I don't have any performance data yet.
-
- 05 3月, 2006 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 12 12月, 2005 1 次提交
-
-
由 Tom Lane 提交于
reduce contention for the former single LockMgrLock. Per my recent proposal. I set it up for 16 partitions, but on a pgbench test this gives only a marginal further improvement over 4 partitions --- we need to test more scenarios to choose the number of partitions.
-
- 09 12月, 2005 1 次提交
-
-
由 Tom Lane 提交于
the data defining the semantics of a lock method (ie, conflict resolution table and ancillary data, which is all constant) and the hash tables storing the current state. The only thing we give up by this is the ability to use separate hashtables for different lock methods, but there is no need for that anyway. Put some extra fields into the LockMethod definition structs to clean up some other uglinesses, like hard-wired tests for DEFAULT_LOCKMETHOD and USER_LOCKMETHOD. This commit doesn't do anything about the performance issues we were discussing, but it clears away some of the underbrush that's in the way of fixing that.
-
- 15 10月, 2005 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 21 8月, 2005 1 次提交
-
-
由 Tom Lane 提交于
to 'Size' (that is, size_t), and install overflow detection checks in it. This allows us to remove the former arbitrary restrictions on NBuffers etc. It won't make any difference in a 32-bit machine, but in a 64-bit machine you could theoretically have terabytes of shared buffers. (How efficiently we could manage 'em remains to be seen.) Similarly, num_temp_buffers, work_mem, and maintenance_work_mem can be set above 2Gb on a 64-bit machine. Original patch from Koichi Suzuki, additional work by moi.
-
- 18 6月, 2005 1 次提交
-
-
由 Tom Lane 提交于
hacking by Alvaro Herrera and Tom Lane.
-
- 15 6月, 2005 1 次提交
-
-
由 Tom Lane 提交于
it is sufficient to track whether a backend holds a lock or not, and store information about transaction vs. session locks only in the inside-the-backend LocalLockTable. Since there can now be but one PROCLOCK per lock per backend, LockCountMyLocks() is no longer needed, thus eliminating some O(N^2) behavior when a backend holds many locks. Also simplify the LockAcquire/LockRelease API by passing just a 'sessionLock' boolean instead of a transaction ID. The previous API was designed with the idea that per-transaction lock holding would be important for subtransactions, but now that we have subtransactions we know that this is unwanted. While at it, add an 'isTempObject' parameter to LockAcquire to indicate whether the lock is being taken on a temp table. This is not used just yet, but will be needed shortly for two-phase commit.
-
- 30 5月, 2005 1 次提交
-
-
由 Tom Lane 提交于
are now reported via elog, eliminating the need to test the result code at most call sites. Make it possible for the caller to distinguish a freshly acquired lock from one already held in the current transaction. Use that capability to avoid redundant AcceptInvalidationMessages() calls in LockRelation().
-
- 20 5月, 2005 1 次提交
-
-
由 Tom Lane 提交于
Also, remove the rather useless return value of LockReleaseAll. Change response to detection of corruption in the shared lock tables to PANIC, since that is the only way of cleaning up fully. Originally an idea of Heikki Linnakangas, variously hacked on by Alvaro Herrera and Tom Lane.
-
- 30 4月, 2005 1 次提交
-
-
由 Tom Lane 提交于
Essentially, we shoehorn in a lockable-object-type field by taking a byte away from the lockmethodid, which can surely fit in one byte instead of two. This allows less artificial definitions of all the other fields of LOCKTAG; we can get rid of the special pg_xactlock pseudo-relation, and also support locks on individual tuples and general database objects (including shared objects). None of those possibilities are actually exploited just yet, however. I removed pg_xactlock from pg_class, but did not force initdb for that change. At this point, relkind 's' (SPECIAL) is unused and could be removed entirely.
-
- 01 1月, 2005 1 次提交
-
-
由 PostgreSQL Daemon 提交于
Tag appropriate files for rc3 Also performed an initial run through of upgrading our Copyright date to extend to 2005 ... first run here was very simple ... change everything where: grep 1996-2004 && the word 'Copyright' ... scanned through the generated list with 'less' first, and after, to make sure that I only picked up the right entries ...
-
- 29 8月, 2004 1 次提交
-
-
由 Bruce Momjian 提交于
-