diff options
author | Peter Eisentraut <peter@eisentraut.org> | 2020-02-17 17:46:37 +0100 |
---|---|---|
committer | Peter Eisentraut <peter@eisentraut.org> | 2020-02-22 12:09:27 +0100 |
commit | 9745f93afc56829f9cf10ca3e43a29f0b4409fe3 (patch) | |
tree | a9c1fd5dcc0c701bceec76fb6243736a37358bf8 /src/backend/access/transam/xlog.c | |
parent | 5f1b8260af961ddf05968c9c3e7f178a3ad5d2ea (diff) | |
download | postgresql-9745f93afc56829f9cf10ca3e43a29f0b4409fe3.tar.gz postgresql-9745f93afc56829f9cf10ca3e43a29f0b4409fe3.zip |
Reformat code comment
Discussion: https://www.postgresql.org/message-id/e8f86ba5-48f1-a80a-7f1d-b76bcb9c5c47@2ndquadrant.com
Diffstat (limited to 'src/backend/access/transam/xlog.c')
-rw-r--r-- | src/backend/access/transam/xlog.c | 21 |
1 files changed, 11 insertions, 10 deletions
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c index 3813eadfb49..b017fd286f2 100644 --- a/src/backend/access/transam/xlog.c +++ b/src/backend/access/transam/xlog.c @@ -6297,16 +6297,17 @@ StartupXLOG(void) /*---------- * If we previously crashed, perform a couple of actions: - * - The pg_wal directory may still include some temporary WAL segments - * used when creating a new segment, so perform some clean up to not - * bloat this path. This is done first as there is no point to sync this - * temporary data. - * - There might be data which we had written, intending to fsync it, - * but which we had not actually fsync'd yet. Therefore, a power failure - * in the near future might cause earlier unflushed writes to be lost, - * even though more recent data written to disk from here on would be - * persisted. To avoid that, fsync the entire data directory. - *--------- + * + * - The pg_wal directory may still include some temporary WAL segments + * used when creating a new segment, so perform some clean up to not + * bloat this path. This is done first as there is no point to sync + * this temporary data. + * + * - There might be data which we had written, intending to fsync it, but + * which we had not actually fsync'd yet. Therefore, a power failure in + * the near future might cause earlier unflushed writes to be lost, even + * though more recent data written to disk from here on would be + * persisted. To avoid that, fsync the entire data directory. */ if (ControlFile->state != DB_SHUTDOWNED && ControlFile->state != DB_SHUTDOWNED_IN_RECOVERY) |