Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit1e9c858

Browse files
committed
pgindent run prior to branching
1 parent2c64d20 commit1e9c858

File tree

18 files changed

+62
-62
lines changed

18 files changed

+62
-62
lines changed

‎contrib/postgres_fdw/postgres_fdw.c‎

Lines changed: 9 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -2020,12 +2020,11 @@ postgresBeginForeignInsert(ModifyTableState *mtstate,
20202020
/*
20212021
* If the foreign table is a partition, we need to create a new RTE
20222022
* describing the foreign table for use by deparseInsertSql and
2023-
* create_foreign_modify() below, after first copying the parent's
2024-
* RTE and modifying some fields to describe the foreign partition to
2025-
* work on. However, if this is invoked by UPDATE, the existing RTE
2026-
* may already correspond to this partition if it is one of the
2027-
* UPDATE subplan target rels; in that case, we can just use the
2028-
* existing RTE as-is.
2023+
* create_foreign_modify() below, after first copying the parent's RTE and
2024+
* modifying some fields to describe the foreign partition to work on.
2025+
* However, if this is invoked by UPDATE, the existing RTE may already
2026+
* correspond to this partition if it is one of the UPDATE subplan target
2027+
* rels; in that case, we can just use the existing RTE as-is.
20292028
*/
20302029
rte=list_nth(estate->es_range_table,resultRelation-1);
20312030
if (rte->relid!=RelationGetRelid(rel))
@@ -2035,10 +2034,10 @@ postgresBeginForeignInsert(ModifyTableState *mtstate,
20352034
rte->relkind=RELKIND_FOREIGN_TABLE;
20362035

20372036
/*
2038-
* For UPDATE, we must use the RT index of the first subplan
2039-
*targetrel's RTE, because the core code would have built
2040-
*expressions forthe partition, such as RETURNING, using that
2041-
*RT index as varno ofVars contained in those expressions.
2037+
* For UPDATE, we must use the RT index of the first subplan target
2038+
* rel's RTE, because the core code would have built expressions for
2039+
* the partition, such as RETURNING, using that RT index as varno of
2040+
* Vars contained in those expressions.
20422041
*/
20432042
if (plan&&plan->operation==CMD_UPDATE&&
20442043
resultRelation==plan->nominalRelation)

‎src/backend/access/gin/ginfast.c‎

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -247,9 +247,9 @@ ginHeapTupleFastInsert(GinState *ginstate, GinTupleCollector *collector)
247247
metapage=BufferGetPage(metabuffer);
248248

249249
/*
250-
* An insertion to the pending list could logically belong anywhere in
251-
*thetree, so it conflicts with all serializable scans. All scans
252-
*acquire apredicate lock on the metabuffer to represent that.
250+
* An insertion to the pending list could logically belong anywhere in the
251+
* tree, so it conflicts with all serializable scans. All scans acquire a
252+
* predicate lock on the metabuffer to represent that.
253253
*/
254254
CheckForSerializableConflictIn(index,NULL,metabuffer);
255255

‎src/backend/access/gin/ginget.c‎

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -235,8 +235,8 @@ collectMatchBitmap(GinBtreeData *btree, GinBtreeStack *stack,
235235
LockBuffer(stack->buffer,GIN_UNLOCK);
236236

237237
/*
238-
* Acquire predicate lock on the posting tree. We already hold
239-
*alock on the entry page, but insertions to the posting tree
238+
* Acquire predicate lock on the posting tree. We already hold a
239+
* lock on the entry page, but insertions to the posting tree
240240
* don't check for conflicts on that level.
241241
*/
242242
PredicateLockPage(btree->index,rootPostingTree,snapshot);
@@ -1766,8 +1766,8 @@ scanPendingInsert(IndexScanDesc scan, TIDBitmap *tbm, int64 *ntids)
17661766
*ntids=0;
17671767

17681768
/*
1769-
* Acquire predicate lock on the metapage, to conflict with any
1770-
*fastupdateinsertions.
1769+
* Acquire predicate lock on the metapage, to conflict with any fastupdate
1770+
* insertions.
17711771
*/
17721772
PredicateLockPage(scan->indexRelation,GIN_METAPAGE_BLKNO,scan->xs_snapshot);
17731773

‎src/backend/access/nbtree/nbtree.c‎

Lines changed: 6 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -820,10 +820,10 @@ _bt_vacuum_needs_cleanup(IndexVacuumInfo *info)
820820

821821
/*
822822
* If table receives enough insertions and no cleanup was performed,
823-
* then index would appear have stale statistics. If scale factor
824-
*isset, we avoid that by performing cleanup if the number of
825-
*insertedtuples exceeds vacuum_cleanup_index_scale_factor fraction
826-
*oforiginal tuples count.
823+
* then index would appear have stale statistics. If scale factor is
824+
* set, we avoid that by performing cleanup if the number of inserted
825+
* tuples exceeds vacuum_cleanup_index_scale_factor fraction of
826+
* original tuples count.
827827
*/
828828
relopts= (StdRdOptions*)info->index->rd_options;
829829
cleanup_scale_factor= (relopts&&
@@ -873,8 +873,8 @@ btbulkdelete(IndexVacuumInfo *info, IndexBulkDeleteResult *stats,
873873
&oldestBtpoXact);
874874

875875
/*
876-
* Update cleanup-related information in metapage. This information
877-
*isused only for cleanup but keeping them up to date can avoid
876+
* Update cleanup-related information in metapage. This information is
877+
* used only for cleanup but keeping them up to date can avoid
878878
* unnecessary cleanup even after bulkdelete.
879879
*/
880880
_bt_update_meta_cleanup_info(info->index,oldestBtpoXact,

‎src/backend/access/nbtree/nbtutils.c‎

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -2196,8 +2196,8 @@ _bt_check_natts(Relation rel, Page page, OffsetNumber offnum)
21962196
* non-zero, or when there is no explicit representation and the
21972197
* tuple is evidently not a pre-pg_upgrade tuple.
21982198
*
2199-
* Prior to v11, downlinks always had P_HIKEY as their offset.
2200-
*Usethat to decide if the tuple is a pre-v11 tuple.
2199+
* Prior to v11, downlinks always had P_HIKEY as their offset. Use
2200+
* that to decide if the tuple is a pre-v11 tuple.
22012201
*/
22022202
returnBTreeTupleGetNAtts(itup,rel)==0||
22032203
((itup->t_info&INDEX_ALT_TID_MASK)==0&&

‎src/backend/access/transam/xlog.c‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -4512,7 +4512,7 @@ ReadControlFile(void)
45124512
errmsg("could not read from control file: %m")));
45134513
else
45144514
ereport(PANIC,
4515-
(errmsg("could not read from control file: read %d bytes, expected %d",r, (int)sizeof(ControlFileData))));
4515+
(errmsg("could not read from control file: read %d bytes, expected %d",r, (int)sizeof(ControlFileData))));
45164516
}
45174517
pgstat_report_wait_end();
45184518

‎src/backend/access/transam/xlogreader.c‎

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -829,9 +829,9 @@ XLogReaderValidatePageHeader(XLogReaderState *state, XLogRecPtr recptr,
829829
}
830830

831831
/*
832-
* Check that the address on the page agrees with what we expected.
833-
*Thischeck typically fails when an old WAL segment is recycled,
834-
*and hasn'tyet been overwritten with new data yet.
832+
* Check that the address on the page agrees with what we expected. This
833+
* check typically fails when an old WAL segment is recycled, and hasn't
834+
* yet been overwritten with new data yet.
835835
*/
836836
if (hdr->xlp_pageaddr!=recaddr)
837837
{

‎src/backend/commands/indexcmds.c‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1002,7 +1002,7 @@ DefineIndex(Oid relationId,
10021002
*/
10031003
foreach(lc,childStmt->indexParams)
10041004
{
1005-
IndexElem*ielem=lfirst(lc);
1005+
IndexElem*ielem=lfirst(lc);
10061006

10071007
/*
10081008
* If the index parameter is an expression, we must

‎src/backend/executor/execMain.c‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1865,7 +1865,7 @@ ExecPartitionCheck(ResultRelInfo *resultRelInfo, TupleTableSlot *slot,
18651865
EState*estate,boolemitError)
18661866
{
18671867
ExprContext*econtext;
1868-
boolsuccess;
1868+
boolsuccess;
18691869

18701870
/*
18711871
* If first time through, build expression state tree for the partition

‎src/backend/replication/logical/reorderbuffer.c‎

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -754,9 +754,9 @@ ReorderBufferAssignChild(ReorderBuffer *rb, TransactionId xid,
754754
else
755755
{
756756
/*
757-
* We already saw this transaction, but initially added it to the list
758-
* of top-level txns. Now that we know it's not top-level, remove
759-
* it from there.
757+
* We already saw this transaction, but initially added it to the
758+
*listof top-level txns. Now that we know it's not top-level,
759+
*removeit from there.
760760
*/
761761
dlist_delete(&subtxn->node);
762762
}

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp