1
0
mirror of https://github.com/postgres/postgres.git synced 2025-11-18 02:02:55 +03:00

Pre-beta mechanical code beautification.

Run pgindent, pgperltidy, and reformat-dat-files.
I manually fixed a couple of comments that pgindent uglified.
This commit is contained in:
Tom Lane
2022-05-12 15:17:30 -04:00
parent 93909599cd
commit 23e7b38bfe
287 changed files with 5193 additions and 3549 deletions

View File

@@ -287,7 +287,7 @@ RelationMapOidToFilenodeForDatabase(char *dbpath, Oid relationId)
void
RelationMapCopy(Oid dbid, Oid tsid, char *srcdbpath, char *dstdbpath)
{
RelMapFile map;
RelMapFile map;
/*
* Read the relmap file from the source database.
@@ -302,8 +302,8 @@ RelationMapCopy(Oid dbid, Oid tsid, char *srcdbpath, char *dstdbpath)
* RelationMappingLock.
*
* There's no point in trying to preserve files here. The new database
* isn't usable yet anyway, and won't ever be if we can't install a
* relmap file.
* isn't usable yet anyway, and won't ever be if we can't install a relmap
* file.
*/
write_relmap_file(&map, true, false, false, dbid, tsid, dstdbpath);
}
@@ -1089,11 +1089,11 @@ relmap_redo(XLogReaderState *record)
* There shouldn't be anyone else updating relmaps during WAL replay,
* but grab the lock to interlock against load_relmap_file().
*
* Note that we use the same WAL record for updating the relmap of
* an existing database as we do for creating a new database. In
* the latter case, taking the relmap log and sending sinval messages
* is unnecessary, but harmless. If we wanted to avoid it, we could
* add a flag to the WAL record to indicate which operation is being
* Note that we use the same WAL record for updating the relmap of an
* existing database as we do for creating a new database. In the
* latter case, taking the relmap log and sending sinval messages is
* unnecessary, but harmless. If we wanted to avoid it, we could add a
* flag to the WAL record to indicate which operation is being
* performed.
*/
LWLockAcquire(RelationMappingLock, LW_EXCLUSIVE);