Skip to content

Commit dd7ea37

Browse files
committed
Fix pgindent damage.
Apparently, I neglected to pgindent the prior commit. Per buildfarm.
1 parent d75c402 commit dd7ea37

File tree

2 files changed

+19
-19
lines changed

2 files changed

+19
-19
lines changed

src/backend/backup/basebackup_incremental.c

+2-2
Original file line numberDiff line numberDiff line change
@@ -778,8 +778,8 @@ GetFileBackupMethod(IncrementalBackupInfo *ib, const char *path,
778778
}
779779

780780
/*
781-
* Look up the special block reference table entry for the database as
782-
* a whole.
781+
* Look up the special block reference table entry for the database as a
782+
* whole.
783783
*/
784784
rlocator.spcOid = spcoid;
785785
rlocator.dbOid = dboid;

src/backend/postmaster/walsummarizer.c

+17-17
Original file line numberDiff line numberDiff line change
@@ -1089,25 +1089,25 @@ SummarizeDbaseRecord(XLogReaderState *xlogreader, BlockRefTable *brtab)
10891089
uint8 info = XLogRecGetInfo(xlogreader) & ~XLR_INFO_MASK;
10901090

10911091
/*
1092-
* We use relfilenode zero for a given database OID and tablespace OID
1093-
* to indicate that all relations with that pair of IDs have been
1094-
* recreated if they exist at all. Effectively, we're setting a limit
1095-
* block of 0 for all such relfilenodes.
1092+
* We use relfilenode zero for a given database OID and tablespace OID to
1093+
* indicate that all relations with that pair of IDs have been recreated
1094+
* if they exist at all. Effectively, we're setting a limit block of 0 for
1095+
* all such relfilenodes.
10961096
*
10971097
* Technically, this special handling is only needed in the case of
1098-
* XLOG_DBASE_CREATE_FILE_COPY, because that can create a whole bunch
1099-
* of relation files in a directory without logging anything
1100-
* specific to each one. If we didn't mark the whole DB OID/TS OID
1101-
* combination in some way, then a tablespace that was dropped after
1102-
* the reference backup and recreated using the FILE_COPY method prior
1103-
* to the incremental backup would look just like one that was never
1104-
* touched at all, which would be catastrophic.
1098+
* XLOG_DBASE_CREATE_FILE_COPY, because that can create a whole bunch of
1099+
* relation files in a directory without logging anything specific to each
1100+
* one. If we didn't mark the whole DB OID/TS OID combination in some way,
1101+
* then a tablespace that was dropped after the reference backup and
1102+
* recreated using the FILE_COPY method prior to the incremental backup
1103+
* would look just like one that was never touched at all, which would be
1104+
* catastrophic.
11051105
*
1106-
* But it seems best to adopt this treatment for all records that drop
1107-
* or create a DB OID/TS OID combination. That's similar to how we
1108-
* treat the limit block for individual relations, and it's an extra
1109-
* layer of safety here. We can never lose data by marking more stuff
1110-
* as needing to be backed up in full.
1106+
* But it seems best to adopt this treatment for all records that drop or
1107+
* create a DB OID/TS OID combination. That's similar to how we treat the
1108+
* limit block for individual relations, and it's an extra layer of safety
1109+
* here. We can never lose data by marking more stuff as needing to be
1110+
* backed up in full.
11111111
*/
11121112
if (info == XLOG_DBASE_CREATE_FILE_COPY)
11131113
{
@@ -1136,7 +1136,7 @@ SummarizeDbaseRecord(XLogReaderState *xlogreader, BlockRefTable *brtab)
11361136
{
11371137
xl_dbase_drop_rec *xlrec;
11381138
RelFileLocator rlocator;
1139-
int i;
1139+
int i;
11401140

11411141
xlrec = (xl_dbase_drop_rec *) XLogRecGetData(xlogreader);
11421142
rlocator.dbOid = xlrec->db_id;

0 commit comments

Comments
 (0)