From 9745f93afc56829f9cf10ca3e43a29f0b4409fe3 Mon Sep 17 00:00:00 2001 From: Peter Eisentraut Date: Mon, 17 Feb 2020 17:46:37 +0100 Subject: [PATCH] Reformat code comment Discussion: https://www.postgresql.org/message-id/e8f86ba5-48f1-a80a-7f1d-b76bcb9c5c47@2ndquadrant.com --- src/backend/access/transam/xlog.c | 21 +++++++++++---------- 1 file 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) -- 2.39.5