diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2023-05-19 17:24:48 -0400 |
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2023-05-19 17:24:48 -0400 |
| commit | 0245f8db36f375326c2bae0c3420d3c77714e72d (patch) | |
| tree | 7ce91f23658a05ea24be4703fb06cdc6b56248f7 /src/backend/utils/cache/relcache.c | |
| parent | df6b19fbbc20d830de91d9bea68715a39635b568 (diff) | |
Pre-beta mechanical code beautification.
Run pgindent, pgperltidy, and reformat-dat-files.
This set of diffs is a bit larger than typical. We've updated to
pg_bsd_indent 2.1.2, which properly indents variable declarations that
have multi-line initialization expressions (the continuation lines are
now indented one tab stop). We've also updated to perltidy version
20230309 and changed some of its settings, which reduces its desire to
add whitespace to lines to make assignments etc. line up. Going
forward, that should make for fewer random-seeming changes to existing
code.
Discussion: https://postgr.es/m/20230428092545.qfb3y5wcu4cm75ur@alvherre.pgsql
Diffstat (limited to 'src/backend/utils/cache/relcache.c')
| -rw-r--r-- | src/backend/utils/cache/relcache.c | 22 |
1 files changed, 11 insertions, 11 deletions
diff --git a/src/backend/utils/cache/relcache.c b/src/backend/utils/cache/relcache.c index 40140de9589..8a08463c2b7 100644 --- a/src/backend/utils/cache/relcache.c +++ b/src/backend/utils/cache/relcache.c @@ -3084,10 +3084,10 @@ static void AssertPendingSyncConsistency(Relation relation) { bool relcache_verdict = - RelationIsPermanent(relation) && - ((relation->rd_createSubid != InvalidSubTransactionId && - RELKIND_HAS_STORAGE(relation->rd_rel->relkind)) || - relation->rd_firstRelfilelocatorSubid != InvalidSubTransactionId); + RelationIsPermanent(relation) && + ((relation->rd_createSubid != InvalidSubTransactionId && + RELKIND_HAS_STORAGE(relation->rd_rel->relkind)) || + relation->rd_firstRelfilelocatorSubid != InvalidSubTransactionId); Assert(relcache_verdict == RelFileLocatorSkippingWAL(relation->rd_locator)); @@ -3765,12 +3765,12 @@ RelationSetNewRelfilenumber(Relation relation, char persistence) */ if (IsBinaryUpgrade) { - SMgrRelation srel; + SMgrRelation srel; /* * During a binary upgrade, we use this code path to ensure that - * pg_largeobject and its index have the same relfilenumbers as in - * the old cluster. This is necessary because pg_upgrade treats + * pg_largeobject and its index have the same relfilenumbers as in the + * old cluster. This is necessary because pg_upgrade treats * pg_largeobject like a user table, not a system table. It is however * possible that a table or index may need to end up with the same * relfilenumber in the new cluster as what it had in the old cluster. @@ -5171,8 +5171,8 @@ RelationGetIndexAttrBitmap(Relation relation, IndexAttrBitmapKind attrKind) Bitmapset *uindexattrs; /* columns in unique indexes */ Bitmapset *pkindexattrs; /* columns in the primary index */ Bitmapset *idindexattrs; /* columns in the replica identity */ - Bitmapset *hotblockingattrs; /* columns with HOT blocking indexes */ - Bitmapset *summarizedattrs; /* columns with summarizing indexes */ + Bitmapset *hotblockingattrs; /* columns with HOT blocking indexes */ + Bitmapset *summarizedattrs; /* columns with summarizing indexes */ List *indexoidlist; List *newindexoidlist; Oid relpkindex; @@ -5314,8 +5314,8 @@ restart: * when the column value changes, thus require a separate * attribute bitmapset. * - * Obviously, non-key columns couldn't be referenced by - * foreign key or identity key. Hence we do not include them into + * Obviously, non-key columns couldn't be referenced by foreign + * key or identity key. Hence we do not include them into * uindexattrs, pkindexattrs and idindexattrs bitmaps. */ if (attrnum != 0) |