- 02 8月, 2007 1 次提交
-
-
由 Tom Lane 提交于
before reporting a transaction committed. Data consistency is still guaranteed (unlike setting fsync = off), but a crash may lose the effects of the last few transactions. Patch by Simon, some editorialization by Tom.
-
- 06 1月, 2007 1 次提交
-
-
由 Bruce Momjian 提交于
back-stamped for this.
-
- 18 11月, 2006 1 次提交
-
-
由 Tom Lane 提交于
cases where we already hold the desired lock "indirectly", either via membership in a MultiXact or because the lock was originally taken by a different subtransaction of the current transaction. These cases must be accounted for to avoid needless deadlocks and/or inappropriate replacement of an exclusive lock with a shared lock. Per report from Clarence Gardner and subsequent investigation.
-
- 04 10月, 2006 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 20 7月, 2006 1 次提交
-
-
由 Tom Lane 提交于
recovery. In the first place, it doesn't work because slru's latest_page_number isn't set up yet (this is why we've been hearing reports of strange "apparent wraparound" log messages during crash recovery, but only from people who'd managed to advance their next-mxact counters some considerable distance from 0). In the second place, it seems a bit unwise to be throwing away data during crash recovery anwyway. This latter consideration convinces me to just disable truncation during recovery, rather than computing latest_page_number and pushing ahead.
-
- 14 7月, 2006 1 次提交
-
-
由 Bruce Momjian 提交于
Strip unused include files out unused include files, and add needed includes to C files. The next step is to remove unused include files in C files.
-
- 12 7月, 2006 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 24 3月, 2006 1 次提交
-
-
由 Tom Lane 提交于
when an error occurs during xlog replay. Also, replace the former risky 'write into a fixed-size buffer with no overflow detection' API for XLOG record description routines; use an expansible StringInfo instead. (The latter accounts for most of the patch bulk.) Qingqing Zhou
-
- 05 3月, 2006 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 07 12月, 2005 2 次提交
-
-
由 Tom Lane 提交于
SLRU area. The number of slots is still a compile-time constant (someday we might want to change that), but at least it's a different constant for each SLRU area. Increase number of subtrans buffers to 32 based on experimentation with a heavily subtrans-bashing test case, and increase number of multixact member buffers to 16, since it's obviously silly for it not to be at least twice the number of multixact offset buffers.
-
由 Tom Lane 提交于
lock, not exclusive, if the desired page is already in memory. This can be demonstrated to be a significant win on the pg_subtrans cache when there is a large window of open transactions. It should be useful for pg_clog as well. I didn't try to make GetMultiXactIdMembers() use the code, as that would have taken some restructuring, and what with the local cache for multixact contents it probably wouldn't really make a difference. Per my recent proposal.
-
- 23 11月, 2005 1 次提交
-
-
由 Bruce Momjian 提交于
comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
-
- 06 11月, 2005 1 次提交
-
-
由 Tom Lane 提交于
for the SLRU race condition that I posted a few days ago, but we decided not to use in 8.1 and older branches.
-
- 29 10月, 2005 2 次提交
-
-
由 Tom Lane 提交于
reserving SLRU space for a new MultiXact. The original coding would have treated out-of-disk-space as a PANIC condition, which is unnecessary.
-
由 Tom Lane 提交于
multixact's starting offset before the offset has been stored into the SLRU file. A simple fix would be to hold the MultiXactGenLock until the offset has been stored, but that looks like a big concurrency hit. Instead rely on knowledge that unset offsets will be zero, and loop when we see a zero. This requires a little extra hacking to ensure that zero is never a valid value for the offset. Problem reported by Matteo Beccati, fix ideas from Martijn van Oosterhout, Alvaro Herrera, and Tom Lane.
-
- 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.
-
- 20 8月, 2005 1 次提交
-
-
由 Tatsuo Ishii 提交于
-
- 02 8月, 2005 1 次提交
-
-
由 Tom Lane 提交于
Original patch by Hans-Juergen Schoenig, revisions by Karel Zak and Tom Lane.
-
- 08 6月, 2005 1 次提交
-
-
由 Tom Lane 提交于
transaction IDs, rather than like subtrans; in particular, the information now survives a database restart. Per previous discussion, this is essential for PITR log shipping and for 2PC.
-
- 20 5月, 2005 1 次提交
-
-
由 Tom Lane 提交于
communication structure, and make it its own module with its own lock. This should reduce contention at least a little, and it definitely makes the code seem cleaner. Per my recent proposal.
-
- 08 5月, 2005 1 次提交
-
-
由 Tom Lane 提交于
-
- 04 5月, 2005 1 次提交
-
-
由 Tom Lane 提交于
are creating a new MultiXactId from two regular XIDs. The original coding was unnecessarily complicated and didn't save any code anyway.
-
- 29 4月, 2005 1 次提交
-
-
由 Tom Lane 提交于
to eliminate unnecessary deadlocks. This commit adds SELECT ... FOR SHARE paralleling SELECT ... FOR UPDATE. The implementation uses a new SLRU data structure (managed much like pg_subtrans) to represent multiple- transaction-ID sets. When more than one transaction is holding a shared lock on a particular row, we create a MultiXactId representing that set of transactions and store its ID in the row's XMAX. This scheme allows an effectively unlimited number of row locks, just as we did before, while not costing any extra overhead except when a shared lock actually has to be shared. Still TODO: use the regular lock manager to control the grant order when multiple backends are waiting for a row lock. Alvaro Herrera and Tom Lane.
-