database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-08-31 17:02:12 +03:00
Code Activity

Re-run pgindent, fixing a problem where comment lines after a blank

Browse Source 
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.
This commit is contained in:
Bruce Momjian
2005-11-22 18:17:34 +00:00
parent e196eedd8a
commit 436a2956d8
264 changed files with 4403 additions and 4097 deletions
Download Patch File Download Diff File Expand all files Collapse all files

30
src/backend/commands/vacuumlazy.c
View File

@@ -31,7 +31,7 @@
*
*
* IDENTIFICATION
* $PostgreSQL: pgsql/src/backend/commands/vacuumlazy.c,v 1.62 2005/11/20 19:49:07 tgl Exp $
* $PostgreSQL: pgsql/src/backend/commands/vacuumlazy.c,v 1.63 2005/11/22 18:17:09 momjian Exp $
*
*-------------------------------------------------------------------------
*/
@@ -286,21 +286,21 @@ lazy_scan_heap(Relation onerel, LVRelStats *vacrelstats,
* relation but crashes before initializing the page. Reclaim such
* pages for use.
*
* We have to be careful here because we could be looking at a page
* that someone has just added to the relation and not yet been
* able to initialize (see RelationGetBufferForTuple). To
* We have to be careful here because we could be looking at a
* page that someone has just added to the relation and not yet
* been able to initialize (see RelationGetBufferForTuple). To
* interlock against that, release the buffer read lock (which we
* must do anyway) and grab the relation extension lock before
* re-locking in exclusive mode. If the page is still
* uninitialized by then, it must be left over from a crashed
* backend, and we can initialize it.
*
* We don't really need the relation lock when this is a new or temp
* relation, but it's probably not worth the code space to check
* that, since this surely isn't a critical path.
* We don't really need the relation lock when this is a new or
* temp relation, but it's probably not worth the code space to
* check that, since this surely isn't a critical path.
*
* Note: the comparable code in vacuum.c need not worry because it's
* got exclusive lock on the whole relation.
* Note: the comparable code in vacuum.c need not worry because
* it's got exclusive lock on the whole relation.
*/
LockBuffer(buf, BUFFER_LOCK_UNLOCK);
LockRelationForExtension(onerel, ExclusiveLock);
@@ -366,12 +366,12 @@ lazy_scan_heap(Relation onerel, LVRelStats *vacrelstats,
* Tuple is good. Consider whether to replace its xmin
* value with FrozenTransactionId.
*
* NB: Since we hold only a shared buffer lock here, we are
* assuming that TransactionId read/write is atomic. This
* is not the only place that makes such an assumption.
* It'd be possible to avoid the assumption by momentarily
* acquiring exclusive lock, but for the moment I see no
* need to.
* NB: Since we hold only a shared buffer lock here, we
* are assuming that TransactionId read/write is atomic.
* This is not the only place that makes such an
* assumption. It'd be possible to avoid the assumption by
* momentarily acquiring exclusive lock, but for the
* moment I see no need to.
*/
if (TransactionIdIsNormal(HeapTupleHeaderGetXmin(tuple.t_data)) &&
TransactionIdPrecedes(HeapTupleHeaderGetXmin(tuple.t_data),