- 28 12月, 2000 1 次提交
-
-
由 Vadim B. Mikheev 提交于
-
- 18 12月, 2000 1 次提交
-
-
由 Tom Lane 提交于
to ensure that we have released buffer refcounts and so forth, rather than putting ad-hoc operations before (some of the calls to) proc_exit. Add commentary to discourage future hackers from repeating that mistake.
-
- 30 11月, 2000 2 次提交
-
-
由 Vadim B. Mikheev 提交于
-
由 Tom Lane 提交于
included by everything that includes bufmgr.h --- it's supposed to be internals, after all, not part of the API! This fixes the conflict against FreeBSD headers reported by Rosenman, by making it unnecessary for s_lock.h to be included by plperl.c.
-
- 29 11月, 2000 1 次提交
-
-
由 Tom Lane 提交于
IPC key assignment will now work correctly even when multiple postmasters are using same logical port number (which is possible given -k switch). There is only one shared-mem segment per postmaster now, not 3. Rip out broken code for non-TAS case in bufmgr and xlog, substitute a complete S_LOCK emulation using semaphores in spin.c. TAS and non-TAS logic is now exactly the same. When deadlock is detected, "Deadlock detected" is now the elog(ERROR) message, rather than a NOTICE that comes out before an unhelpful ERROR.
-
- 09 11月, 2000 1 次提交
-
-
由 Tom Lane 提交于
(WAL logging for this is not done yet, however.) Clean up a number of really crufty things that are no longer needed now that DROP behaves nicely. Make temp table mapper do the right things when drop or rename affecting a temp table is rolled back. Also, remove "relation modified while in use" error check, in favor of locking tables at first reference and holding that lock throughout the statement.
-
- 29 10月, 2000 1 次提交
-
-
由 Vadim B. Mikheev 提交于
-
- 20 10月, 2000 1 次提交
-
-
由 Vadim B. Mikheev 提交于
-
- 08 8月, 2000 1 次提交
-
-
由 Tom Lane 提交于
as MaxHeapAttributeNumber. Increase MaxAttrSize to something more reasonable (given what it's used for, namely checking char(n) declarations, I didn't make it the full 1G that it could theoretically be --- 10Mb seemed a more reasonable number). Improve calculation of MaxTupleSize.
-
- 15 6月, 2000 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 19 5月, 2000 1 次提交
-
-
由 Tom Lane 提交于
Hiroshi. ReleaseRelationBuffers now removes rel's buffers from pool, instead of merely marking them nondirty. The old code would leave valid buffers for a deleted relation, which didn't cause any known problems but can't possibly be a good idea. There were several places which called ReleaseRelationBuffers *and* FlushRelationBuffers, which is now unnecessary; but there were others that did not. FlushRelationBuffers no longer emits a warning notice if it finds dirty buffers to flush, because with the current bufmgr behavior that's not an unexpected condition. Also, FlushRelationBuffers will flush out all dirty buffers for the relation regardless of block number. This ensures that pg_upgrade's expectations are met about tuple on-row status bits being up-to-date on disk. Lastly, tweak BufTableDelete() to clear the buffer's tag so that no one can mistake it for being a still-valid buffer for the page it once held. Formerly, the buffer would not be found by buffer hashtable searches after BufTableDelete(), but it would still be thought to belong to its old relation by the routines that sequentially scan the shared-buffer array. Again I know of no bugs caused by that, but it still can't be a good idea.
-
- 13 4月, 2000 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 09 4月, 2000 1 次提交
-
-
由 Tom Lane 提交于
as a shared dirtybit for each shared buffer. The shared dirtybit still controls writing the buffer, but the local bit controls whether we need to fsync the buffer's file. This arrangement fixes a bug that allowed some required fsyncs to be missed, and should improve performance as well. For more info see my post of same date on pghackers.
-
- 31 3月, 2000 1 次提交
-
-
由 Tom Lane 提交于
In the event of an elog() while the mode was set to immediate write, there was no way for it to be set back to the normal delayed write. The mechanism was a waste of space and cycles anyway, since the only user was varsup.c, which could perfectly well call FlushBuffer directly. Now it does just that, and the notion of a write mode is gone.
-
- 26 1月, 2000 1 次提交
-
-
由 Bruce Momjian 提交于
* Portions Copyright (c) 1996-2000, PostgreSQL, Inc to all files copyright Regents of Berkeley. Man, that's a lot of files.
-
- 17 1月, 2000 1 次提交
-
-
由 Hiroshi Inoue 提交于
Fix for TODO item * spinlock stuck problem when elog(FATAL) and elog(ERROR) inside bufmgr.
-
- 28 9月, 1999 1 次提交
-
-
由 Vadim B. Mikheev 提交于
-
- 24 9月, 1999 2 次提交
-
-
由 Tom Lane 提交于
* Buffer refcount cleanup (per my "progress report" to pghackers, 9/22). * Add links to backend PROC structs to sinval's array of per-backend info, and use these links for routines that need to check the state of all backends (rather than the slow, complicated search of the ShmemIndex hashtable that was used before). Add databaseOID to PROC structs. * Use this to implement an interlock that prevents DESTROY DATABASE of a database containing running backends. (It's a little tricky to prevent a concurrently-starting backend from getting in there, since the new backend is not able to lock anything at the time it tries to look up its database in pg_database. My solution is to recheck that the DB is OK at the end of InitPostgres. It may not be a 100% solution, but it's a lot better than no interlock at all...) * In ALTER TABLE RENAME, flush buffers for the relation before doing the rename of the physical files, to ensure we don't get failures later from mdblindwrt(). * Update TRUNCATE patch so that it actually compiles against current sources :-(. You should do "make clean all" after pulling these changes.
-
由 Bruce Momjian 提交于
-
- 18 7月, 1999 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 16 7月, 1999 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 15 7月, 1999 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 26 5月, 1999 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 14 2月, 1999 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 15 12月, 1998 1 次提交
-
-
由 Vadim B. Mikheev 提交于
New code for locking buffer' context.
-
- 09 10月, 1998 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 01 9月, 1998 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 19 8月, 1998 1 次提交
-
-
由 Bruce Momjian 提交于
no longer returns buffer pointer, can be gotten from scan; descriptor; bootstrap can create multi-key indexes; pg_procname index now is multi-key index; oidint2, oidint4, oidname are gone (must be removed from regression tests); use System Cache rather than sequential scan in many places; heap_modifytuple no longer takes buffer parameter; remove unused buffer parameter in a few other functions; oid8 is not index-able; remove some use of single-character variable names; cleanup Buffer variables usage and scan descriptor looping; cleaned up allocation and freeing of tuples; 18k lines of diff;
-
- 16 6月, 1998 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 24 4月, 1998 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 26 2月, 1998 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 25 1月, 1998 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 13 1月, 1998 1 次提交
-
-
由 Marc G. Fournier 提交于
========================================== What follows is a set of diffs that cleans up the usage of BLCKSZ. As a side effect, the person compiling the code can change the value of BLCKSZ _at_their_own_risk_. By that, I mean that I've tried it here at 4096 and 16384 with no ill-effects. A value of 4096 _shouldn't_ affect much as far as the kernel/file system goes, but making it bigger than 8192 can have severe consequences if you don't know what you're doing. 16394 worked for me, _BUT_ when I went to 32768 and did an initdb, the SCSI driver broke and the partition that I was running under went to hell in a hand basket. Had to reboot and do a good bit of fsck'ing to fix things up. The patch can be safely applied though. Just leave BLCKSZ = 8192 and everything is as before. It basically only cleans up all of the references to BLCKSZ in the code. If this patch is applied, a comment in the config.h file though above the BLCKSZ define with warning about monkeying around with it would be a good idea. Darren darrenk@insightdist.com (Also cleans up some of the #includes in files referencing BLCKSZ.) ==========================================
-
- 09 9月, 1997 2 次提交
-
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
- 08 9月, 1997 1 次提交
-
-
由 Bruce Momjian 提交于
Another PGINDENT run that changes variable indenting and case label indenting. Also static variable indenting.
-
- 07 9月, 1997 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 20 8月, 1997 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 28 3月, 1997 1 次提交
-
-
由 Marc G. Fournier 提交于
Reply-To: hackers@hub.org, Dan McGuirk <mcguirk@indirect.com> To: hackers@hub.org Subject: [HACKERS] tmin writeback optimization I was doing some profiling of the backend, and noticed that during a certain benchmark I was running somewhere between 30% and 75% of the backend's CPU time was being spent in calls to TransactionIdDidCommit() from HeapTupleSatisfiesNow() or HeapTupleSatisfiesItself() to determine that changed rows' transactions had in fact been committed even though the rows' tmin values had not yet been set. When a query looks at a given row, it needs to figure out whether the transaction that changed the row has been committed and hence it should pay attention to the row, or whether on the other hand the transaction is still in progress or has been aborted and hence the row should be ignored. If a tmin value is set, it is known definitively that the row's transaction has been committed. However, if tmin is not set, the transaction referred to in xmin must be looked up in pg_log, and this is what the backend was spending a lot of time doing during my benchmark. So, implementing a method suggested by Vadim, I created the following patch that, the first time a query finds a committed row whose tmin value is not set, sets it, and marks the buffer where the row is stored as dirty. (It works for tmax, too.) This doesn't result in the boost in real time performance I was hoping for, however it does decrease backend CPU usage by up to two-thirds in certain situations, so it could be rather beneficial in high-concurrency settings.
-
- 16 1月, 1997 1 次提交
-
-
由 Vadim B. Mikheev 提交于
release buffer if called from WriteNoReleaseBuffer ())
-