2016-09-29 18:00:00 +02:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
|
|
|
* File-processing utility routines.
|
|
|
|
*
|
|
|
|
* Assorted utility functions to work on files.
|
|
|
|
*
|
|
|
|
*
|
2023-01-02 21:00:37 +01:00
|
|
|
* Portions Copyright (c) 1996-2023, PostgreSQL Global Development Group
|
2016-09-29 18:00:00 +02:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
|
|
|
*
|
|
|
|
* src/common/file_utils.c
|
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
2020-06-30 06:26:11 +02:00
|
|
|
|
|
|
|
#ifndef FRONTEND
|
2020-09-07 08:11:46 +02:00
|
|
|
#include "postgres.h"
|
|
|
|
#else
|
2016-09-29 18:00:00 +02:00
|
|
|
#include "postgres_fe.h"
|
2020-09-07 08:11:46 +02:00
|
|
|
#endif
|
2016-09-29 18:00:00 +02:00
|
|
|
|
|
|
|
#include <dirent.h>
|
|
|
|
#include <fcntl.h>
|
|
|
|
#include <sys/stat.h>
|
|
|
|
#include <unistd.h>
|
|
|
|
|
|
|
|
#include "common/file_utils.h"
|
2020-09-07 08:11:46 +02:00
|
|
|
#ifdef FRONTEND
|
2019-05-14 20:19:49 +02:00
|
|
|
#include "common/logging.h"
|
2020-09-07 08:11:46 +02:00
|
|
|
#endif
|
2022-10-27 07:39:42 +02:00
|
|
|
#include "port/pg_iovec.h"
|
2016-09-29 18:00:00 +02:00
|
|
|
|
2020-09-07 08:11:46 +02:00
|
|
|
#ifdef FRONTEND
|
2016-09-29 18:00:00 +02:00
|
|
|
|
|
|
|
/* Define PG_FLUSH_DATA_WORKS if we have an implementation for pg_flush_data */
|
|
|
|
#if defined(HAVE_SYNC_FILE_RANGE)
|
|
|
|
#define PG_FLUSH_DATA_WORKS 1
|
|
|
|
#elif defined(USE_POSIX_FADVISE) && defined(POSIX_FADV_DONTNEED)
|
|
|
|
#define PG_FLUSH_DATA_WORKS 1
|
|
|
|
#endif
|
|
|
|
|
2016-10-20 17:24:37 +02:00
|
|
|
/*
|
|
|
|
* pg_xlog has been renamed to pg_wal in version 10.
|
|
|
|
*/
|
|
|
|
#define MINIMUM_VERSION_FOR_PG_WAL 100000
|
|
|
|
|
2016-09-29 18:00:00 +02:00
|
|
|
#ifdef PG_FLUSH_DATA_WORKS
|
Unified logging system for command-line programs
This unifies the various ad hoc logging (message printing, error
printing) systems used throughout the command-line programs.
Features:
- Program name is automatically prefixed.
- Message string does not end with newline. This removes a common
source of inconsistencies and omissions.
- Additionally, a final newline is automatically stripped, simplifying
use of PQerrorMessage() etc., another common source of mistakes.
- I converted error message strings to use %m where possible.
- As a result of the above several points, more translatable message
strings can be shared between different components and between
frontends and backend, without gratuitous punctuation or whitespace
differences.
- There is support for setting a "log level". This is not meant to be
user-facing, but can be used internally to implement debug or
verbose modes.
- Lazy argument evaluation, so no significant overhead if logging at
some level is disabled.
- Some color in the messages, similar to gcc and clang. Set
PG_COLOR=auto to try it out. Some colors are predefined, but can be
customized by setting PG_COLORS.
- Common files (common/, fe_utils/, etc.) can handle logging much more
simply by just using one API without worrying too much about the
context of the calling program, requiring callbacks, or having to
pass "progname" around everywhere.
- Some programs called setvbuf() to make sure that stderr is
unbuffered, even on Windows. But not all programs did that. This
is now done centrally.
Soft goals:
- Reduces vertical space use and visual complexity of error reporting
in the source code.
- Encourages more deliberate classification of messages. For example,
in some cases it wasn't clear without analyzing the surrounding code
whether a message was meant as an error or just an info.
- Concepts and terms are vaguely aligned with popular logging
frameworks such as log4j and Python logging.
This is all just about printing stuff out. Nothing affects program
flow (e.g., fatal exits). The uses are just too varied to do that.
Some existing code had wrappers that do some kind of print-and-exit,
and I adapted those.
I tried to keep the output mostly the same, but there is a lot of
historical baggage to unwind and special cases to consider, and I
might not always have succeeded. One significant change is that
pg_rewind used to write all error messages to stdout. That is now
changed to stderr.
Reviewed-by: Donald Dong <xdong@csumb.edu>
Reviewed-by: Arthur Zakirov <a.zakirov@postgrespro.ru>
Discussion: https://www.postgresql.org/message-id/flat/6a609b43-4f57-7348-6480-bd022f924310@2ndquadrant.com
2019-04-01 14:24:37 +02:00
|
|
|
static int pre_sync_fname(const char *fname, bool isdir);
|
2016-09-29 18:00:00 +02:00
|
|
|
#endif
|
|
|
|
static void walkdir(const char *path,
|
Unified logging system for command-line programs
This unifies the various ad hoc logging (message printing, error
printing) systems used throughout the command-line programs.
Features:
- Program name is automatically prefixed.
- Message string does not end with newline. This removes a common
source of inconsistencies and omissions.
- Additionally, a final newline is automatically stripped, simplifying
use of PQerrorMessage() etc., another common source of mistakes.
- I converted error message strings to use %m where possible.
- As a result of the above several points, more translatable message
strings can be shared between different components and between
frontends and backend, without gratuitous punctuation or whitespace
differences.
- There is support for setting a "log level". This is not meant to be
user-facing, but can be used internally to implement debug or
verbose modes.
- Lazy argument evaluation, so no significant overhead if logging at
some level is disabled.
- Some color in the messages, similar to gcc and clang. Set
PG_COLOR=auto to try it out. Some colors are predefined, but can be
customized by setting PG_COLORS.
- Common files (common/, fe_utils/, etc.) can handle logging much more
simply by just using one API without worrying too much about the
context of the calling program, requiring callbacks, or having to
pass "progname" around everywhere.
- Some programs called setvbuf() to make sure that stderr is
unbuffered, even on Windows. But not all programs did that. This
is now done centrally.
Soft goals:
- Reduces vertical space use and visual complexity of error reporting
in the source code.
- Encourages more deliberate classification of messages. For example,
in some cases it wasn't clear without analyzing the surrounding code
whether a message was meant as an error or just an info.
- Concepts and terms are vaguely aligned with popular logging
frameworks such as log4j and Python logging.
This is all just about printing stuff out. Nothing affects program
flow (e.g., fatal exits). The uses are just too varied to do that.
Some existing code had wrappers that do some kind of print-and-exit,
and I adapted those.
I tried to keep the output mostly the same, but there is a lot of
historical baggage to unwind and special cases to consider, and I
might not always have succeeded. One significant change is that
pg_rewind used to write all error messages to stdout. That is now
changed to stderr.
Reviewed-by: Donald Dong <xdong@csumb.edu>
Reviewed-by: Arthur Zakirov <a.zakirov@postgrespro.ru>
Discussion: https://www.postgresql.org/message-id/flat/6a609b43-4f57-7348-6480-bd022f924310@2ndquadrant.com
2019-04-01 14:24:37 +02:00
|
|
|
int (*action) (const char *fname, bool isdir),
|
|
|
|
bool process_symlinks);
|
2016-09-29 18:00:00 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Issue fsync recursively on PGDATA and all its contents.
|
|
|
|
*
|
2016-10-20 17:24:37 +02:00
|
|
|
* We fsync regular files and directories wherever they are, but we follow
|
|
|
|
* symlinks only for pg_wal (or pg_xlog) and immediately under pg_tblspc.
|
|
|
|
* Other symlinks are presumed to point at files we're not responsible for
|
|
|
|
* fsyncing, and might not have privileges to write at all.
|
|
|
|
*
|
|
|
|
* serverVersion indicates the version of the server to be fsync'd.
|
2016-09-29 18:00:00 +02:00
|
|
|
*/
|
|
|
|
void
|
2016-10-20 17:24:37 +02:00
|
|
|
fsync_pgdata(const char *pg_data,
|
|
|
|
int serverVersion)
|
2016-09-29 18:00:00 +02:00
|
|
|
{
|
|
|
|
bool xlog_is_symlink;
|
2016-10-20 17:24:37 +02:00
|
|
|
char pg_wal[MAXPGPATH];
|
2016-09-29 18:00:00 +02:00
|
|
|
char pg_tblspc[MAXPGPATH];
|
|
|
|
|
2016-10-20 17:24:37 +02:00
|
|
|
/* handle renaming of pg_xlog to pg_wal in post-10 clusters */
|
|
|
|
snprintf(pg_wal, MAXPGPATH, "%s/%s", pg_data,
|
|
|
|
serverVersion < MINIMUM_VERSION_FOR_PG_WAL ? "pg_xlog" : "pg_wal");
|
2016-09-29 18:00:00 +02:00
|
|
|
snprintf(pg_tblspc, MAXPGPATH, "%s/pg_tblspc", pg_data);
|
|
|
|
|
|
|
|
/*
|
2016-10-20 17:24:37 +02:00
|
|
|
* If pg_wal is a symlink, we'll need to recurse into it separately,
|
2016-09-29 18:00:00 +02:00
|
|
|
* because the first walkdir below will ignore it.
|
|
|
|
*/
|
|
|
|
xlog_is_symlink = false;
|
|
|
|
|
|
|
|
{
|
|
|
|
struct stat st;
|
|
|
|
|
2016-10-20 17:24:37 +02:00
|
|
|
if (lstat(pg_wal, &st) < 0)
|
Unified logging system for command-line programs
This unifies the various ad hoc logging (message printing, error
printing) systems used throughout the command-line programs.
Features:
- Program name is automatically prefixed.
- Message string does not end with newline. This removes a common
source of inconsistencies and omissions.
- Additionally, a final newline is automatically stripped, simplifying
use of PQerrorMessage() etc., another common source of mistakes.
- I converted error message strings to use %m where possible.
- As a result of the above several points, more translatable message
strings can be shared between different components and between
frontends and backend, without gratuitous punctuation or whitespace
differences.
- There is support for setting a "log level". This is not meant to be
user-facing, but can be used internally to implement debug or
verbose modes.
- Lazy argument evaluation, so no significant overhead if logging at
some level is disabled.
- Some color in the messages, similar to gcc and clang. Set
PG_COLOR=auto to try it out. Some colors are predefined, but can be
customized by setting PG_COLORS.
- Common files (common/, fe_utils/, etc.) can handle logging much more
simply by just using one API without worrying too much about the
context of the calling program, requiring callbacks, or having to
pass "progname" around everywhere.
- Some programs called setvbuf() to make sure that stderr is
unbuffered, even on Windows. But not all programs did that. This
is now done centrally.
Soft goals:
- Reduces vertical space use and visual complexity of error reporting
in the source code.
- Encourages more deliberate classification of messages. For example,
in some cases it wasn't clear without analyzing the surrounding code
whether a message was meant as an error or just an info.
- Concepts and terms are vaguely aligned with popular logging
frameworks such as log4j and Python logging.
This is all just about printing stuff out. Nothing affects program
flow (e.g., fatal exits). The uses are just too varied to do that.
Some existing code had wrappers that do some kind of print-and-exit,
and I adapted those.
I tried to keep the output mostly the same, but there is a lot of
historical baggage to unwind and special cases to consider, and I
might not always have succeeded. One significant change is that
pg_rewind used to write all error messages to stdout. That is now
changed to stderr.
Reviewed-by: Donald Dong <xdong@csumb.edu>
Reviewed-by: Arthur Zakirov <a.zakirov@postgrespro.ru>
Discussion: https://www.postgresql.org/message-id/flat/6a609b43-4f57-7348-6480-bd022f924310@2ndquadrant.com
2019-04-01 14:24:37 +02:00
|
|
|
pg_log_error("could not stat file \"%s\": %m", pg_wal);
|
2016-09-29 18:00:00 +02:00
|
|
|
else if (S_ISLNK(st.st_mode))
|
|
|
|
xlog_is_symlink = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If possible, hint to the kernel that we're soon going to fsync the data
|
|
|
|
* directory and its contents.
|
|
|
|
*/
|
|
|
|
#ifdef PG_FLUSH_DATA_WORKS
|
Unified logging system for command-line programs
This unifies the various ad hoc logging (message printing, error
printing) systems used throughout the command-line programs.
Features:
- Program name is automatically prefixed.
- Message string does not end with newline. This removes a common
source of inconsistencies and omissions.
- Additionally, a final newline is automatically stripped, simplifying
use of PQerrorMessage() etc., another common source of mistakes.
- I converted error message strings to use %m where possible.
- As a result of the above several points, more translatable message
strings can be shared between different components and between
frontends and backend, without gratuitous punctuation or whitespace
differences.
- There is support for setting a "log level". This is not meant to be
user-facing, but can be used internally to implement debug or
verbose modes.
- Lazy argument evaluation, so no significant overhead if logging at
some level is disabled.
- Some color in the messages, similar to gcc and clang. Set
PG_COLOR=auto to try it out. Some colors are predefined, but can be
customized by setting PG_COLORS.
- Common files (common/, fe_utils/, etc.) can handle logging much more
simply by just using one API without worrying too much about the
context of the calling program, requiring callbacks, or having to
pass "progname" around everywhere.
- Some programs called setvbuf() to make sure that stderr is
unbuffered, even on Windows. But not all programs did that. This
is now done centrally.
Soft goals:
- Reduces vertical space use and visual complexity of error reporting
in the source code.
- Encourages more deliberate classification of messages. For example,
in some cases it wasn't clear without analyzing the surrounding code
whether a message was meant as an error or just an info.
- Concepts and terms are vaguely aligned with popular logging
frameworks such as log4j and Python logging.
This is all just about printing stuff out. Nothing affects program
flow (e.g., fatal exits). The uses are just too varied to do that.
Some existing code had wrappers that do some kind of print-and-exit,
and I adapted those.
I tried to keep the output mostly the same, but there is a lot of
historical baggage to unwind and special cases to consider, and I
might not always have succeeded. One significant change is that
pg_rewind used to write all error messages to stdout. That is now
changed to stderr.
Reviewed-by: Donald Dong <xdong@csumb.edu>
Reviewed-by: Arthur Zakirov <a.zakirov@postgrespro.ru>
Discussion: https://www.postgresql.org/message-id/flat/6a609b43-4f57-7348-6480-bd022f924310@2ndquadrant.com
2019-04-01 14:24:37 +02:00
|
|
|
walkdir(pg_data, pre_sync_fname, false);
|
2016-09-29 18:00:00 +02:00
|
|
|
if (xlog_is_symlink)
|
Unified logging system for command-line programs
This unifies the various ad hoc logging (message printing, error
printing) systems used throughout the command-line programs.
Features:
- Program name is automatically prefixed.
- Message string does not end with newline. This removes a common
source of inconsistencies and omissions.
- Additionally, a final newline is automatically stripped, simplifying
use of PQerrorMessage() etc., another common source of mistakes.
- I converted error message strings to use %m where possible.
- As a result of the above several points, more translatable message
strings can be shared between different components and between
frontends and backend, without gratuitous punctuation or whitespace
differences.
- There is support for setting a "log level". This is not meant to be
user-facing, but can be used internally to implement debug or
verbose modes.
- Lazy argument evaluation, so no significant overhead if logging at
some level is disabled.
- Some color in the messages, similar to gcc and clang. Set
PG_COLOR=auto to try it out. Some colors are predefined, but can be
customized by setting PG_COLORS.
- Common files (common/, fe_utils/, etc.) can handle logging much more
simply by just using one API without worrying too much about the
context of the calling program, requiring callbacks, or having to
pass "progname" around everywhere.
- Some programs called setvbuf() to make sure that stderr is
unbuffered, even on Windows. But not all programs did that. This
is now done centrally.
Soft goals:
- Reduces vertical space use and visual complexity of error reporting
in the source code.
- Encourages more deliberate classification of messages. For example,
in some cases it wasn't clear without analyzing the surrounding code
whether a message was meant as an error or just an info.
- Concepts and terms are vaguely aligned with popular logging
frameworks such as log4j and Python logging.
This is all just about printing stuff out. Nothing affects program
flow (e.g., fatal exits). The uses are just too varied to do that.
Some existing code had wrappers that do some kind of print-and-exit,
and I adapted those.
I tried to keep the output mostly the same, but there is a lot of
historical baggage to unwind and special cases to consider, and I
might not always have succeeded. One significant change is that
pg_rewind used to write all error messages to stdout. That is now
changed to stderr.
Reviewed-by: Donald Dong <xdong@csumb.edu>
Reviewed-by: Arthur Zakirov <a.zakirov@postgrespro.ru>
Discussion: https://www.postgresql.org/message-id/flat/6a609b43-4f57-7348-6480-bd022f924310@2ndquadrant.com
2019-04-01 14:24:37 +02:00
|
|
|
walkdir(pg_wal, pre_sync_fname, false);
|
|
|
|
walkdir(pg_tblspc, pre_sync_fname, true);
|
2016-09-29 18:00:00 +02:00
|
|
|
#endif
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Now we do the fsync()s in the same order.
|
|
|
|
*
|
|
|
|
* The main call ignores symlinks, so in addition to specially processing
|
2016-10-20 17:24:37 +02:00
|
|
|
* pg_wal if it's a symlink, pg_tblspc has to be visited separately with
|
2016-09-29 18:00:00 +02:00
|
|
|
* process_symlinks = true. Note that if there are any plain directories
|
|
|
|
* in pg_tblspc, they'll get fsync'd twice. That's not an expected case
|
|
|
|
* so we don't worry about optimizing it.
|
|
|
|
*/
|
Unified logging system for command-line programs
This unifies the various ad hoc logging (message printing, error
printing) systems used throughout the command-line programs.
Features:
- Program name is automatically prefixed.
- Message string does not end with newline. This removes a common
source of inconsistencies and omissions.
- Additionally, a final newline is automatically stripped, simplifying
use of PQerrorMessage() etc., another common source of mistakes.
- I converted error message strings to use %m where possible.
- As a result of the above several points, more translatable message
strings can be shared between different components and between
frontends and backend, without gratuitous punctuation or whitespace
differences.
- There is support for setting a "log level". This is not meant to be
user-facing, but can be used internally to implement debug or
verbose modes.
- Lazy argument evaluation, so no significant overhead if logging at
some level is disabled.
- Some color in the messages, similar to gcc and clang. Set
PG_COLOR=auto to try it out. Some colors are predefined, but can be
customized by setting PG_COLORS.
- Common files (common/, fe_utils/, etc.) can handle logging much more
simply by just using one API without worrying too much about the
context of the calling program, requiring callbacks, or having to
pass "progname" around everywhere.
- Some programs called setvbuf() to make sure that stderr is
unbuffered, even on Windows. But not all programs did that. This
is now done centrally.
Soft goals:
- Reduces vertical space use and visual complexity of error reporting
in the source code.
- Encourages more deliberate classification of messages. For example,
in some cases it wasn't clear without analyzing the surrounding code
whether a message was meant as an error or just an info.
- Concepts and terms are vaguely aligned with popular logging
frameworks such as log4j and Python logging.
This is all just about printing stuff out. Nothing affects program
flow (e.g., fatal exits). The uses are just too varied to do that.
Some existing code had wrappers that do some kind of print-and-exit,
and I adapted those.
I tried to keep the output mostly the same, but there is a lot of
historical baggage to unwind and special cases to consider, and I
might not always have succeeded. One significant change is that
pg_rewind used to write all error messages to stdout. That is now
changed to stderr.
Reviewed-by: Donald Dong <xdong@csumb.edu>
Reviewed-by: Arthur Zakirov <a.zakirov@postgrespro.ru>
Discussion: https://www.postgresql.org/message-id/flat/6a609b43-4f57-7348-6480-bd022f924310@2ndquadrant.com
2019-04-01 14:24:37 +02:00
|
|
|
walkdir(pg_data, fsync_fname, false);
|
2016-09-29 18:00:00 +02:00
|
|
|
if (xlog_is_symlink)
|
Unified logging system for command-line programs
This unifies the various ad hoc logging (message printing, error
printing) systems used throughout the command-line programs.
Features:
- Program name is automatically prefixed.
- Message string does not end with newline. This removes a common
source of inconsistencies and omissions.
- Additionally, a final newline is automatically stripped, simplifying
use of PQerrorMessage() etc., another common source of mistakes.
- I converted error message strings to use %m where possible.
- As a result of the above several points, more translatable message
strings can be shared between different components and between
frontends and backend, without gratuitous punctuation or whitespace
differences.
- There is support for setting a "log level". This is not meant to be
user-facing, but can be used internally to implement debug or
verbose modes.
- Lazy argument evaluation, so no significant overhead if logging at
some level is disabled.
- Some color in the messages, similar to gcc and clang. Set
PG_COLOR=auto to try it out. Some colors are predefined, but can be
customized by setting PG_COLORS.
- Common files (common/, fe_utils/, etc.) can handle logging much more
simply by just using one API without worrying too much about the
context of the calling program, requiring callbacks, or having to
pass "progname" around everywhere.
- Some programs called setvbuf() to make sure that stderr is
unbuffered, even on Windows. But not all programs did that. This
is now done centrally.
Soft goals:
- Reduces vertical space use and visual complexity of error reporting
in the source code.
- Encourages more deliberate classification of messages. For example,
in some cases it wasn't clear without analyzing the surrounding code
whether a message was meant as an error or just an info.
- Concepts and terms are vaguely aligned with popular logging
frameworks such as log4j and Python logging.
This is all just about printing stuff out. Nothing affects program
flow (e.g., fatal exits). The uses are just too varied to do that.
Some existing code had wrappers that do some kind of print-and-exit,
and I adapted those.
I tried to keep the output mostly the same, but there is a lot of
historical baggage to unwind and special cases to consider, and I
might not always have succeeded. One significant change is that
pg_rewind used to write all error messages to stdout. That is now
changed to stderr.
Reviewed-by: Donald Dong <xdong@csumb.edu>
Reviewed-by: Arthur Zakirov <a.zakirov@postgrespro.ru>
Discussion: https://www.postgresql.org/message-id/flat/6a609b43-4f57-7348-6480-bd022f924310@2ndquadrant.com
2019-04-01 14:24:37 +02:00
|
|
|
walkdir(pg_wal, fsync_fname, false);
|
|
|
|
walkdir(pg_tblspc, fsync_fname, true);
|
2016-09-29 18:00:00 +02:00
|
|
|
}
|
|
|
|
|
2017-03-22 15:00:30 +01:00
|
|
|
/*
|
|
|
|
* Issue fsync recursively on the given directory and all its contents.
|
|
|
|
*
|
|
|
|
* This is a convenient wrapper on top of walkdir().
|
|
|
|
*/
|
|
|
|
void
|
Unified logging system for command-line programs
This unifies the various ad hoc logging (message printing, error
printing) systems used throughout the command-line programs.
Features:
- Program name is automatically prefixed.
- Message string does not end with newline. This removes a common
source of inconsistencies and omissions.
- Additionally, a final newline is automatically stripped, simplifying
use of PQerrorMessage() etc., another common source of mistakes.
- I converted error message strings to use %m where possible.
- As a result of the above several points, more translatable message
strings can be shared between different components and between
frontends and backend, without gratuitous punctuation or whitespace
differences.
- There is support for setting a "log level". This is not meant to be
user-facing, but can be used internally to implement debug or
verbose modes.
- Lazy argument evaluation, so no significant overhead if logging at
some level is disabled.
- Some color in the messages, similar to gcc and clang. Set
PG_COLOR=auto to try it out. Some colors are predefined, but can be
customized by setting PG_COLORS.
- Common files (common/, fe_utils/, etc.) can handle logging much more
simply by just using one API without worrying too much about the
context of the calling program, requiring callbacks, or having to
pass "progname" around everywhere.
- Some programs called setvbuf() to make sure that stderr is
unbuffered, even on Windows. But not all programs did that. This
is now done centrally.
Soft goals:
- Reduces vertical space use and visual complexity of error reporting
in the source code.
- Encourages more deliberate classification of messages. For example,
in some cases it wasn't clear without analyzing the surrounding code
whether a message was meant as an error or just an info.
- Concepts and terms are vaguely aligned with popular logging
frameworks such as log4j and Python logging.
This is all just about printing stuff out. Nothing affects program
flow (e.g., fatal exits). The uses are just too varied to do that.
Some existing code had wrappers that do some kind of print-and-exit,
and I adapted those.
I tried to keep the output mostly the same, but there is a lot of
historical baggage to unwind and special cases to consider, and I
might not always have succeeded. One significant change is that
pg_rewind used to write all error messages to stdout. That is now
changed to stderr.
Reviewed-by: Donald Dong <xdong@csumb.edu>
Reviewed-by: Arthur Zakirov <a.zakirov@postgrespro.ru>
Discussion: https://www.postgresql.org/message-id/flat/6a609b43-4f57-7348-6480-bd022f924310@2ndquadrant.com
2019-04-01 14:24:37 +02:00
|
|
|
fsync_dir_recurse(const char *dir)
|
2017-03-22 15:00:30 +01:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
* If possible, hint to the kernel that we're soon going to fsync the data
|
|
|
|
* directory and its contents.
|
|
|
|
*/
|
|
|
|
#ifdef PG_FLUSH_DATA_WORKS
|
Unified logging system for command-line programs
This unifies the various ad hoc logging (message printing, error
printing) systems used throughout the command-line programs.
Features:
- Program name is automatically prefixed.
- Message string does not end with newline. This removes a common
source of inconsistencies and omissions.
- Additionally, a final newline is automatically stripped, simplifying
use of PQerrorMessage() etc., another common source of mistakes.
- I converted error message strings to use %m where possible.
- As a result of the above several points, more translatable message
strings can be shared between different components and between
frontends and backend, without gratuitous punctuation or whitespace
differences.
- There is support for setting a "log level". This is not meant to be
user-facing, but can be used internally to implement debug or
verbose modes.
- Lazy argument evaluation, so no significant overhead if logging at
some level is disabled.
- Some color in the messages, similar to gcc and clang. Set
PG_COLOR=auto to try it out. Some colors are predefined, but can be
customized by setting PG_COLORS.
- Common files (common/, fe_utils/, etc.) can handle logging much more
simply by just using one API without worrying too much about the
context of the calling program, requiring callbacks, or having to
pass "progname" around everywhere.
- Some programs called setvbuf() to make sure that stderr is
unbuffered, even on Windows. But not all programs did that. This
is now done centrally.
Soft goals:
- Reduces vertical space use and visual complexity of error reporting
in the source code.
- Encourages more deliberate classification of messages. For example,
in some cases it wasn't clear without analyzing the surrounding code
whether a message was meant as an error or just an info.
- Concepts and terms are vaguely aligned with popular logging
frameworks such as log4j and Python logging.
This is all just about printing stuff out. Nothing affects program
flow (e.g., fatal exits). The uses are just too varied to do that.
Some existing code had wrappers that do some kind of print-and-exit,
and I adapted those.
I tried to keep the output mostly the same, but there is a lot of
historical baggage to unwind and special cases to consider, and I
might not always have succeeded. One significant change is that
pg_rewind used to write all error messages to stdout. That is now
changed to stderr.
Reviewed-by: Donald Dong <xdong@csumb.edu>
Reviewed-by: Arthur Zakirov <a.zakirov@postgrespro.ru>
Discussion: https://www.postgresql.org/message-id/flat/6a609b43-4f57-7348-6480-bd022f924310@2ndquadrant.com
2019-04-01 14:24:37 +02:00
|
|
|
walkdir(dir, pre_sync_fname, false);
|
2017-03-22 15:00:30 +01:00
|
|
|
#endif
|
|
|
|
|
Unified logging system for command-line programs
This unifies the various ad hoc logging (message printing, error
printing) systems used throughout the command-line programs.
Features:
- Program name is automatically prefixed.
- Message string does not end with newline. This removes a common
source of inconsistencies and omissions.
- Additionally, a final newline is automatically stripped, simplifying
use of PQerrorMessage() etc., another common source of mistakes.
- I converted error message strings to use %m where possible.
- As a result of the above several points, more translatable message
strings can be shared between different components and between
frontends and backend, without gratuitous punctuation or whitespace
differences.
- There is support for setting a "log level". This is not meant to be
user-facing, but can be used internally to implement debug or
verbose modes.
- Lazy argument evaluation, so no significant overhead if logging at
some level is disabled.
- Some color in the messages, similar to gcc and clang. Set
PG_COLOR=auto to try it out. Some colors are predefined, but can be
customized by setting PG_COLORS.
- Common files (common/, fe_utils/, etc.) can handle logging much more
simply by just using one API without worrying too much about the
context of the calling program, requiring callbacks, or having to
pass "progname" around everywhere.
- Some programs called setvbuf() to make sure that stderr is
unbuffered, even on Windows. But not all programs did that. This
is now done centrally.
Soft goals:
- Reduces vertical space use and visual complexity of error reporting
in the source code.
- Encourages more deliberate classification of messages. For example,
in some cases it wasn't clear without analyzing the surrounding code
whether a message was meant as an error or just an info.
- Concepts and terms are vaguely aligned with popular logging
frameworks such as log4j and Python logging.
This is all just about printing stuff out. Nothing affects program
flow (e.g., fatal exits). The uses are just too varied to do that.
Some existing code had wrappers that do some kind of print-and-exit,
and I adapted those.
I tried to keep the output mostly the same, but there is a lot of
historical baggage to unwind and special cases to consider, and I
might not always have succeeded. One significant change is that
pg_rewind used to write all error messages to stdout. That is now
changed to stderr.
Reviewed-by: Donald Dong <xdong@csumb.edu>
Reviewed-by: Arthur Zakirov <a.zakirov@postgrespro.ru>
Discussion: https://www.postgresql.org/message-id/flat/6a609b43-4f57-7348-6480-bd022f924310@2ndquadrant.com
2019-04-01 14:24:37 +02:00
|
|
|
walkdir(dir, fsync_fname, false);
|
2017-03-22 15:00:30 +01:00
|
|
|
}
|
|
|
|
|
2016-09-29 18:00:00 +02:00
|
|
|
/*
|
|
|
|
* walkdir: recursively walk a directory, applying the action to each
|
|
|
|
* regular file and directory (including the named directory itself).
|
|
|
|
*
|
|
|
|
* If process_symlinks is true, the action and recursion are also applied
|
|
|
|
* to regular files and directories that are pointed to by symlinks in the
|
|
|
|
* given directory; otherwise symlinks are ignored. Symlinks are always
|
|
|
|
* ignored in subdirectories, ie we intentionally don't pass down the
|
|
|
|
* process_symlinks flag to recursive calls.
|
|
|
|
*
|
|
|
|
* Errors are reported but not considered fatal.
|
|
|
|
*
|
|
|
|
* See also walkdir in fd.c, which is a backend version of this logic.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
walkdir(const char *path,
|
Unified logging system for command-line programs
This unifies the various ad hoc logging (message printing, error
printing) systems used throughout the command-line programs.
Features:
- Program name is automatically prefixed.
- Message string does not end with newline. This removes a common
source of inconsistencies and omissions.
- Additionally, a final newline is automatically stripped, simplifying
use of PQerrorMessage() etc., another common source of mistakes.
- I converted error message strings to use %m where possible.
- As a result of the above several points, more translatable message
strings can be shared between different components and between
frontends and backend, without gratuitous punctuation or whitespace
differences.
- There is support for setting a "log level". This is not meant to be
user-facing, but can be used internally to implement debug or
verbose modes.
- Lazy argument evaluation, so no significant overhead if logging at
some level is disabled.
- Some color in the messages, similar to gcc and clang. Set
PG_COLOR=auto to try it out. Some colors are predefined, but can be
customized by setting PG_COLORS.
- Common files (common/, fe_utils/, etc.) can handle logging much more
simply by just using one API without worrying too much about the
context of the calling program, requiring callbacks, or having to
pass "progname" around everywhere.
- Some programs called setvbuf() to make sure that stderr is
unbuffered, even on Windows. But not all programs did that. This
is now done centrally.
Soft goals:
- Reduces vertical space use and visual complexity of error reporting
in the source code.
- Encourages more deliberate classification of messages. For example,
in some cases it wasn't clear without analyzing the surrounding code
whether a message was meant as an error or just an info.
- Concepts and terms are vaguely aligned with popular logging
frameworks such as log4j and Python logging.
This is all just about printing stuff out. Nothing affects program
flow (e.g., fatal exits). The uses are just too varied to do that.
Some existing code had wrappers that do some kind of print-and-exit,
and I adapted those.
I tried to keep the output mostly the same, but there is a lot of
historical baggage to unwind and special cases to consider, and I
might not always have succeeded. One significant change is that
pg_rewind used to write all error messages to stdout. That is now
changed to stderr.
Reviewed-by: Donald Dong <xdong@csumb.edu>
Reviewed-by: Arthur Zakirov <a.zakirov@postgrespro.ru>
Discussion: https://www.postgresql.org/message-id/flat/6a609b43-4f57-7348-6480-bd022f924310@2ndquadrant.com
2019-04-01 14:24:37 +02:00
|
|
|
int (*action) (const char *fname, bool isdir),
|
|
|
|
bool process_symlinks)
|
2016-09-29 18:00:00 +02:00
|
|
|
{
|
|
|
|
DIR *dir;
|
|
|
|
struct dirent *de;
|
|
|
|
|
|
|
|
dir = opendir(path);
|
|
|
|
if (dir == NULL)
|
|
|
|
{
|
Unified logging system for command-line programs
This unifies the various ad hoc logging (message printing, error
printing) systems used throughout the command-line programs.
Features:
- Program name is automatically prefixed.
- Message string does not end with newline. This removes a common
source of inconsistencies and omissions.
- Additionally, a final newline is automatically stripped, simplifying
use of PQerrorMessage() etc., another common source of mistakes.
- I converted error message strings to use %m where possible.
- As a result of the above several points, more translatable message
strings can be shared between different components and between
frontends and backend, without gratuitous punctuation or whitespace
differences.
- There is support for setting a "log level". This is not meant to be
user-facing, but can be used internally to implement debug or
verbose modes.
- Lazy argument evaluation, so no significant overhead if logging at
some level is disabled.
- Some color in the messages, similar to gcc and clang. Set
PG_COLOR=auto to try it out. Some colors are predefined, but can be
customized by setting PG_COLORS.
- Common files (common/, fe_utils/, etc.) can handle logging much more
simply by just using one API without worrying too much about the
context of the calling program, requiring callbacks, or having to
pass "progname" around everywhere.
- Some programs called setvbuf() to make sure that stderr is
unbuffered, even on Windows. But not all programs did that. This
is now done centrally.
Soft goals:
- Reduces vertical space use and visual complexity of error reporting
in the source code.
- Encourages more deliberate classification of messages. For example,
in some cases it wasn't clear without analyzing the surrounding code
whether a message was meant as an error or just an info.
- Concepts and terms are vaguely aligned with popular logging
frameworks such as log4j and Python logging.
This is all just about printing stuff out. Nothing affects program
flow (e.g., fatal exits). The uses are just too varied to do that.
Some existing code had wrappers that do some kind of print-and-exit,
and I adapted those.
I tried to keep the output mostly the same, but there is a lot of
historical baggage to unwind and special cases to consider, and I
might not always have succeeded. One significant change is that
pg_rewind used to write all error messages to stdout. That is now
changed to stderr.
Reviewed-by: Donald Dong <xdong@csumb.edu>
Reviewed-by: Arthur Zakirov <a.zakirov@postgrespro.ru>
Discussion: https://www.postgresql.org/message-id/flat/6a609b43-4f57-7348-6480-bd022f924310@2ndquadrant.com
2019-04-01 14:24:37 +02:00
|
|
|
pg_log_error("could not open directory \"%s\": %m", path);
|
2016-09-29 18:00:00 +02:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
while (errno = 0, (de = readdir(dir)) != NULL)
|
|
|
|
{
|
2017-04-11 20:13:31 +02:00
|
|
|
char subpath[MAXPGPATH * 2];
|
2016-09-29 18:00:00 +02:00
|
|
|
|
|
|
|
if (strcmp(de->d_name, ".") == 0 ||
|
|
|
|
strcmp(de->d_name, "..") == 0)
|
|
|
|
continue;
|
|
|
|
|
2017-04-11 20:13:31 +02:00
|
|
|
snprintf(subpath, sizeof(subpath), "%s/%s", path, de->d_name);
|
2016-09-29 18:00:00 +02:00
|
|
|
|
2020-09-07 08:11:46 +02:00
|
|
|
switch (get_dirent_type(subpath, de, process_symlinks, PG_LOG_ERROR))
|
2016-09-29 18:00:00 +02:00
|
|
|
{
|
2020-09-07 08:11:46 +02:00
|
|
|
case PGFILETYPE_REG:
|
|
|
|
(*action) (subpath, false);
|
|
|
|
break;
|
|
|
|
case PGFILETYPE_DIR:
|
|
|
|
walkdir(subpath, action, false);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Errors are already reported directly by get_dirent_type(),
|
|
|
|
* and any remaining symlinks and unknown file types are
|
|
|
|
* ignored.
|
|
|
|
*/
|
|
|
|
break;
|
2016-09-29 18:00:00 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (errno)
|
Unified logging system for command-line programs
This unifies the various ad hoc logging (message printing, error
printing) systems used throughout the command-line programs.
Features:
- Program name is automatically prefixed.
- Message string does not end with newline. This removes a common
source of inconsistencies and omissions.
- Additionally, a final newline is automatically stripped, simplifying
use of PQerrorMessage() etc., another common source of mistakes.
- I converted error message strings to use %m where possible.
- As a result of the above several points, more translatable message
strings can be shared between different components and between
frontends and backend, without gratuitous punctuation or whitespace
differences.
- There is support for setting a "log level". This is not meant to be
user-facing, but can be used internally to implement debug or
verbose modes.
- Lazy argument evaluation, so no significant overhead if logging at
some level is disabled.
- Some color in the messages, similar to gcc and clang. Set
PG_COLOR=auto to try it out. Some colors are predefined, but can be
customized by setting PG_COLORS.
- Common files (common/, fe_utils/, etc.) can handle logging much more
simply by just using one API without worrying too much about the
context of the calling program, requiring callbacks, or having to
pass "progname" around everywhere.
- Some programs called setvbuf() to make sure that stderr is
unbuffered, even on Windows. But not all programs did that. This
is now done centrally.
Soft goals:
- Reduces vertical space use and visual complexity of error reporting
in the source code.
- Encourages more deliberate classification of messages. For example,
in some cases it wasn't clear without analyzing the surrounding code
whether a message was meant as an error or just an info.
- Concepts and terms are vaguely aligned with popular logging
frameworks such as log4j and Python logging.
This is all just about printing stuff out. Nothing affects program
flow (e.g., fatal exits). The uses are just too varied to do that.
Some existing code had wrappers that do some kind of print-and-exit,
and I adapted those.
I tried to keep the output mostly the same, but there is a lot of
historical baggage to unwind and special cases to consider, and I
might not always have succeeded. One significant change is that
pg_rewind used to write all error messages to stdout. That is now
changed to stderr.
Reviewed-by: Donald Dong <xdong@csumb.edu>
Reviewed-by: Arthur Zakirov <a.zakirov@postgrespro.ru>
Discussion: https://www.postgresql.org/message-id/flat/6a609b43-4f57-7348-6480-bd022f924310@2ndquadrant.com
2019-04-01 14:24:37 +02:00
|
|
|
pg_log_error("could not read directory \"%s\": %m", path);
|
2016-09-29 18:00:00 +02:00
|
|
|
|
|
|
|
(void) closedir(dir);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* It's important to fsync the destination directory itself as individual
|
|
|
|
* file fsyncs don't guarantee that the directory entry for the file is
|
|
|
|
* synced. Recent versions of ext4 have made the window much wider but
|
|
|
|
* it's been an issue for ext3 and other filesystems in the past.
|
|
|
|
*/
|
Unified logging system for command-line programs
This unifies the various ad hoc logging (message printing, error
printing) systems used throughout the command-line programs.
Features:
- Program name is automatically prefixed.
- Message string does not end with newline. This removes a common
source of inconsistencies and omissions.
- Additionally, a final newline is automatically stripped, simplifying
use of PQerrorMessage() etc., another common source of mistakes.
- I converted error message strings to use %m where possible.
- As a result of the above several points, more translatable message
strings can be shared between different components and between
frontends and backend, without gratuitous punctuation or whitespace
differences.
- There is support for setting a "log level". This is not meant to be
user-facing, but can be used internally to implement debug or
verbose modes.
- Lazy argument evaluation, so no significant overhead if logging at
some level is disabled.
- Some color in the messages, similar to gcc and clang. Set
PG_COLOR=auto to try it out. Some colors are predefined, but can be
customized by setting PG_COLORS.
- Common files (common/, fe_utils/, etc.) can handle logging much more
simply by just using one API without worrying too much about the
context of the calling program, requiring callbacks, or having to
pass "progname" around everywhere.
- Some programs called setvbuf() to make sure that stderr is
unbuffered, even on Windows. But not all programs did that. This
is now done centrally.
Soft goals:
- Reduces vertical space use and visual complexity of error reporting
in the source code.
- Encourages more deliberate classification of messages. For example,
in some cases it wasn't clear without analyzing the surrounding code
whether a message was meant as an error or just an info.
- Concepts and terms are vaguely aligned with popular logging
frameworks such as log4j and Python logging.
This is all just about printing stuff out. Nothing affects program
flow (e.g., fatal exits). The uses are just too varied to do that.
Some existing code had wrappers that do some kind of print-and-exit,
and I adapted those.
I tried to keep the output mostly the same, but there is a lot of
historical baggage to unwind and special cases to consider, and I
might not always have succeeded. One significant change is that
pg_rewind used to write all error messages to stdout. That is now
changed to stderr.
Reviewed-by: Donald Dong <xdong@csumb.edu>
Reviewed-by: Arthur Zakirov <a.zakirov@postgrespro.ru>
Discussion: https://www.postgresql.org/message-id/flat/6a609b43-4f57-7348-6480-bd022f924310@2ndquadrant.com
2019-04-01 14:24:37 +02:00
|
|
|
(*action) (path, true);
|
2016-09-29 18:00:00 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Hint to the OS that it should get ready to fsync() this file.
|
|
|
|
*
|
|
|
|
* Ignores errors trying to open unreadable files, and reports other errors
|
|
|
|
* non-fatally.
|
|
|
|
*/
|
|
|
|
#ifdef PG_FLUSH_DATA_WORKS
|
|
|
|
|
2016-09-29 18:00:00 +02:00
|
|
|
static int
|
Unified logging system for command-line programs
This unifies the various ad hoc logging (message printing, error
printing) systems used throughout the command-line programs.
Features:
- Program name is automatically prefixed.
- Message string does not end with newline. This removes a common
source of inconsistencies and omissions.
- Additionally, a final newline is automatically stripped, simplifying
use of PQerrorMessage() etc., another common source of mistakes.
- I converted error message strings to use %m where possible.
- As a result of the above several points, more translatable message
strings can be shared between different components and between
frontends and backend, without gratuitous punctuation or whitespace
differences.
- There is support for setting a "log level". This is not meant to be
user-facing, but can be used internally to implement debug or
verbose modes.
- Lazy argument evaluation, so no significant overhead if logging at
some level is disabled.
- Some color in the messages, similar to gcc and clang. Set
PG_COLOR=auto to try it out. Some colors are predefined, but can be
customized by setting PG_COLORS.
- Common files (common/, fe_utils/, etc.) can handle logging much more
simply by just using one API without worrying too much about the
context of the calling program, requiring callbacks, or having to
pass "progname" around everywhere.
- Some programs called setvbuf() to make sure that stderr is
unbuffered, even on Windows. But not all programs did that. This
is now done centrally.
Soft goals:
- Reduces vertical space use and visual complexity of error reporting
in the source code.
- Encourages more deliberate classification of messages. For example,
in some cases it wasn't clear without analyzing the surrounding code
whether a message was meant as an error or just an info.
- Concepts and terms are vaguely aligned with popular logging
frameworks such as log4j and Python logging.
This is all just about printing stuff out. Nothing affects program
flow (e.g., fatal exits). The uses are just too varied to do that.
Some existing code had wrappers that do some kind of print-and-exit,
and I adapted those.
I tried to keep the output mostly the same, but there is a lot of
historical baggage to unwind and special cases to consider, and I
might not always have succeeded. One significant change is that
pg_rewind used to write all error messages to stdout. That is now
changed to stderr.
Reviewed-by: Donald Dong <xdong@csumb.edu>
Reviewed-by: Arthur Zakirov <a.zakirov@postgrespro.ru>
Discussion: https://www.postgresql.org/message-id/flat/6a609b43-4f57-7348-6480-bd022f924310@2ndquadrant.com
2019-04-01 14:24:37 +02:00
|
|
|
pre_sync_fname(const char *fname, bool isdir)
|
2016-09-29 18:00:00 +02:00
|
|
|
{
|
|
|
|
int fd;
|
|
|
|
|
2018-09-14 03:04:14 +02:00
|
|
|
fd = open(fname, O_RDONLY | PG_BINARY, 0);
|
2016-09-29 18:00:00 +02:00
|
|
|
|
|
|
|
if (fd < 0)
|
|
|
|
{
|
|
|
|
if (errno == EACCES || (isdir && errno == EISDIR))
|
2016-09-29 18:00:00 +02:00
|
|
|
return 0;
|
Unified logging system for command-line programs
This unifies the various ad hoc logging (message printing, error
printing) systems used throughout the command-line programs.
Features:
- Program name is automatically prefixed.
- Message string does not end with newline. This removes a common
source of inconsistencies and omissions.
- Additionally, a final newline is automatically stripped, simplifying
use of PQerrorMessage() etc., another common source of mistakes.
- I converted error message strings to use %m where possible.
- As a result of the above several points, more translatable message
strings can be shared between different components and between
frontends and backend, without gratuitous punctuation or whitespace
differences.
- There is support for setting a "log level". This is not meant to be
user-facing, but can be used internally to implement debug or
verbose modes.
- Lazy argument evaluation, so no significant overhead if logging at
some level is disabled.
- Some color in the messages, similar to gcc and clang. Set
PG_COLOR=auto to try it out. Some colors are predefined, but can be
customized by setting PG_COLORS.
- Common files (common/, fe_utils/, etc.) can handle logging much more
simply by just using one API without worrying too much about the
context of the calling program, requiring callbacks, or having to
pass "progname" around everywhere.
- Some programs called setvbuf() to make sure that stderr is
unbuffered, even on Windows. But not all programs did that. This
is now done centrally.
Soft goals:
- Reduces vertical space use and visual complexity of error reporting
in the source code.
- Encourages more deliberate classification of messages. For example,
in some cases it wasn't clear without analyzing the surrounding code
whether a message was meant as an error or just an info.
- Concepts and terms are vaguely aligned with popular logging
frameworks such as log4j and Python logging.
This is all just about printing stuff out. Nothing affects program
flow (e.g., fatal exits). The uses are just too varied to do that.
Some existing code had wrappers that do some kind of print-and-exit,
and I adapted those.
I tried to keep the output mostly the same, but there is a lot of
historical baggage to unwind and special cases to consider, and I
might not always have succeeded. One significant change is that
pg_rewind used to write all error messages to stdout. That is now
changed to stderr.
Reviewed-by: Donald Dong <xdong@csumb.edu>
Reviewed-by: Arthur Zakirov <a.zakirov@postgrespro.ru>
Discussion: https://www.postgresql.org/message-id/flat/6a609b43-4f57-7348-6480-bd022f924310@2ndquadrant.com
2019-04-01 14:24:37 +02:00
|
|
|
pg_log_error("could not open file \"%s\": %m", fname);
|
2016-09-29 18:00:00 +02:00
|
|
|
return -1;
|
2016-09-29 18:00:00 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We do what pg_flush_data() would do in the backend: prefer to use
|
|
|
|
* sync_file_range, but fall back to posix_fadvise. We ignore errors
|
|
|
|
* because this is only a hint.
|
|
|
|
*/
|
|
|
|
#if defined(HAVE_SYNC_FILE_RANGE)
|
|
|
|
(void) sync_file_range(fd, 0, 0, SYNC_FILE_RANGE_WRITE);
|
|
|
|
#elif defined(USE_POSIX_FADVISE) && defined(POSIX_FADV_DONTNEED)
|
|
|
|
(void) posix_fadvise(fd, 0, 0, POSIX_FADV_DONTNEED);
|
|
|
|
#else
|
|
|
|
#error PG_FLUSH_DATA_WORKS should not have been defined
|
|
|
|
#endif
|
|
|
|
|
|
|
|
(void) close(fd);
|
2016-09-29 18:00:00 +02:00
|
|
|
return 0;
|
2016-09-29 18:00:00 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
#endif /* PG_FLUSH_DATA_WORKS */
|
|
|
|
|
|
|
|
/*
|
|
|
|
* fsync_fname -- Try to fsync a file or directory
|
|
|
|
*
|
|
|
|
* Ignores errors trying to open unreadable files, or trying to fsync
|
2020-02-24 16:32:34 +01:00
|
|
|
* directories on systems where that isn't allowed/required. All other errors
|
|
|
|
* are fatal.
|
2016-09-29 18:00:00 +02:00
|
|
|
*/
|
2016-09-29 18:00:00 +02:00
|
|
|
int
|
Unified logging system for command-line programs
This unifies the various ad hoc logging (message printing, error
printing) systems used throughout the command-line programs.
Features:
- Program name is automatically prefixed.
- Message string does not end with newline. This removes a common
source of inconsistencies and omissions.
- Additionally, a final newline is automatically stripped, simplifying
use of PQerrorMessage() etc., another common source of mistakes.
- I converted error message strings to use %m where possible.
- As a result of the above several points, more translatable message
strings can be shared between different components and between
frontends and backend, without gratuitous punctuation or whitespace
differences.
- There is support for setting a "log level". This is not meant to be
user-facing, but can be used internally to implement debug or
verbose modes.
- Lazy argument evaluation, so no significant overhead if logging at
some level is disabled.
- Some color in the messages, similar to gcc and clang. Set
PG_COLOR=auto to try it out. Some colors are predefined, but can be
customized by setting PG_COLORS.
- Common files (common/, fe_utils/, etc.) can handle logging much more
simply by just using one API without worrying too much about the
context of the calling program, requiring callbacks, or having to
pass "progname" around everywhere.
- Some programs called setvbuf() to make sure that stderr is
unbuffered, even on Windows. But not all programs did that. This
is now done centrally.
Soft goals:
- Reduces vertical space use and visual complexity of error reporting
in the source code.
- Encourages more deliberate classification of messages. For example,
in some cases it wasn't clear without analyzing the surrounding code
whether a message was meant as an error or just an info.
- Concepts and terms are vaguely aligned with popular logging
frameworks such as log4j and Python logging.
This is all just about printing stuff out. Nothing affects program
flow (e.g., fatal exits). The uses are just too varied to do that.
Some existing code had wrappers that do some kind of print-and-exit,
and I adapted those.
I tried to keep the output mostly the same, but there is a lot of
historical baggage to unwind and special cases to consider, and I
might not always have succeeded. One significant change is that
pg_rewind used to write all error messages to stdout. That is now
changed to stderr.
Reviewed-by: Donald Dong <xdong@csumb.edu>
Reviewed-by: Arthur Zakirov <a.zakirov@postgrespro.ru>
Discussion: https://www.postgresql.org/message-id/flat/6a609b43-4f57-7348-6480-bd022f924310@2ndquadrant.com
2019-04-01 14:24:37 +02:00
|
|
|
fsync_fname(const char *fname, bool isdir)
|
2016-09-29 18:00:00 +02:00
|
|
|
{
|
|
|
|
int fd;
|
|
|
|
int flags;
|
|
|
|
int returncode;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Some OSs require directories to be opened read-only whereas other
|
|
|
|
* systems don't allow us to fsync files opened read-only; so we need both
|
|
|
|
* cases here. Using O_RDWR will cause us to fail to fsync files that are
|
|
|
|
* not writable by our userid, but we assume that's OK.
|
|
|
|
*/
|
|
|
|
flags = PG_BINARY;
|
|
|
|
if (!isdir)
|
|
|
|
flags |= O_RDWR;
|
|
|
|
else
|
|
|
|
flags |= O_RDONLY;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Open the file, silently ignoring errors about unreadable files (or
|
|
|
|
* unsupported operations, e.g. opening a directory under Windows), and
|
|
|
|
* logging others.
|
|
|
|
*/
|
2018-09-14 03:04:14 +02:00
|
|
|
fd = open(fname, flags, 0);
|
2016-09-29 18:00:00 +02:00
|
|
|
if (fd < 0)
|
|
|
|
{
|
|
|
|
if (errno == EACCES || (isdir && errno == EISDIR))
|
2016-09-29 18:00:00 +02:00
|
|
|
return 0;
|
Unified logging system for command-line programs
This unifies the various ad hoc logging (message printing, error
printing) systems used throughout the command-line programs.
Features:
- Program name is automatically prefixed.
- Message string does not end with newline. This removes a common
source of inconsistencies and omissions.
- Additionally, a final newline is automatically stripped, simplifying
use of PQerrorMessage() etc., another common source of mistakes.
- I converted error message strings to use %m where possible.
- As a result of the above several points, more translatable message
strings can be shared between different components and between
frontends and backend, without gratuitous punctuation or whitespace
differences.
- There is support for setting a "log level". This is not meant to be
user-facing, but can be used internally to implement debug or
verbose modes.
- Lazy argument evaluation, so no significant overhead if logging at
some level is disabled.
- Some color in the messages, similar to gcc and clang. Set
PG_COLOR=auto to try it out. Some colors are predefined, but can be
customized by setting PG_COLORS.
- Common files (common/, fe_utils/, etc.) can handle logging much more
simply by just using one API without worrying too much about the
context of the calling program, requiring callbacks, or having to
pass "progname" around everywhere.
- Some programs called setvbuf() to make sure that stderr is
unbuffered, even on Windows. But not all programs did that. This
is now done centrally.
Soft goals:
- Reduces vertical space use and visual complexity of error reporting
in the source code.
- Encourages more deliberate classification of messages. For example,
in some cases it wasn't clear without analyzing the surrounding code
whether a message was meant as an error or just an info.
- Concepts and terms are vaguely aligned with popular logging
frameworks such as log4j and Python logging.
This is all just about printing stuff out. Nothing affects program
flow (e.g., fatal exits). The uses are just too varied to do that.
Some existing code had wrappers that do some kind of print-and-exit,
and I adapted those.
I tried to keep the output mostly the same, but there is a lot of
historical baggage to unwind and special cases to consider, and I
might not always have succeeded. One significant change is that
pg_rewind used to write all error messages to stdout. That is now
changed to stderr.
Reviewed-by: Donald Dong <xdong@csumb.edu>
Reviewed-by: Arthur Zakirov <a.zakirov@postgrespro.ru>
Discussion: https://www.postgresql.org/message-id/flat/6a609b43-4f57-7348-6480-bd022f924310@2ndquadrant.com
2019-04-01 14:24:37 +02:00
|
|
|
pg_log_error("could not open file \"%s\": %m", fname);
|
2016-09-29 18:00:00 +02:00
|
|
|
return -1;
|
2016-09-29 18:00:00 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
returncode = fsync(fd);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Some OSes don't allow us to fsync directories at all, so we can ignore
|
|
|
|
* those errors. Anything else needs to be reported.
|
|
|
|
*/
|
2019-02-24 11:48:52 +01:00
|
|
|
if (returncode != 0 && !(isdir && (errno == EBADF || errno == EINVAL)))
|
2016-09-29 18:00:00 +02:00
|
|
|
{
|
2022-04-08 20:55:14 +02:00
|
|
|
pg_log_error("could not fsync file \"%s\": %m", fname);
|
2016-10-02 18:33:46 +02:00
|
|
|
(void) close(fd);
|
2020-02-24 16:32:34 +01:00
|
|
|
exit(EXIT_FAILURE);
|
2016-09-29 18:00:00 +02:00
|
|
|
}
|
2016-09-29 18:00:00 +02:00
|
|
|
|
|
|
|
(void) close(fd);
|
2016-09-29 18:00:00 +02:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* fsync_parent_path -- fsync the parent path of a file or directory
|
|
|
|
*
|
|
|
|
* This is aimed at making file operations persistent on disk in case of
|
|
|
|
* an OS crash or power failure.
|
|
|
|
*/
|
|
|
|
int
|
Unified logging system for command-line programs
This unifies the various ad hoc logging (message printing, error
printing) systems used throughout the command-line programs.
Features:
- Program name is automatically prefixed.
- Message string does not end with newline. This removes a common
source of inconsistencies and omissions.
- Additionally, a final newline is automatically stripped, simplifying
use of PQerrorMessage() etc., another common source of mistakes.
- I converted error message strings to use %m where possible.
- As a result of the above several points, more translatable message
strings can be shared between different components and between
frontends and backend, without gratuitous punctuation or whitespace
differences.
- There is support for setting a "log level". This is not meant to be
user-facing, but can be used internally to implement debug or
verbose modes.
- Lazy argument evaluation, so no significant overhead if logging at
some level is disabled.
- Some color in the messages, similar to gcc and clang. Set
PG_COLOR=auto to try it out. Some colors are predefined, but can be
customized by setting PG_COLORS.
- Common files (common/, fe_utils/, etc.) can handle logging much more
simply by just using one API without worrying too much about the
context of the calling program, requiring callbacks, or having to
pass "progname" around everywhere.
- Some programs called setvbuf() to make sure that stderr is
unbuffered, even on Windows. But not all programs did that. This
is now done centrally.
Soft goals:
- Reduces vertical space use and visual complexity of error reporting
in the source code.
- Encourages more deliberate classification of messages. For example,
in some cases it wasn't clear without analyzing the surrounding code
whether a message was meant as an error or just an info.
- Concepts and terms are vaguely aligned with popular logging
frameworks such as log4j and Python logging.
This is all just about printing stuff out. Nothing affects program
flow (e.g., fatal exits). The uses are just too varied to do that.
Some existing code had wrappers that do some kind of print-and-exit,
and I adapted those.
I tried to keep the output mostly the same, but there is a lot of
historical baggage to unwind and special cases to consider, and I
might not always have succeeded. One significant change is that
pg_rewind used to write all error messages to stdout. That is now
changed to stderr.
Reviewed-by: Donald Dong <xdong@csumb.edu>
Reviewed-by: Arthur Zakirov <a.zakirov@postgrespro.ru>
Discussion: https://www.postgresql.org/message-id/flat/6a609b43-4f57-7348-6480-bd022f924310@2ndquadrant.com
2019-04-01 14:24:37 +02:00
|
|
|
fsync_parent_path(const char *fname)
|
2016-09-29 18:00:00 +02:00
|
|
|
{
|
|
|
|
char parentpath[MAXPGPATH];
|
|
|
|
|
|
|
|
strlcpy(parentpath, fname, MAXPGPATH);
|
|
|
|
get_parent_directory(parentpath);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* get_parent_directory() returns an empty string if the input argument is
|
|
|
|
* just a file name (see comments in path.c), so handle that as being the
|
|
|
|
* current directory.
|
|
|
|
*/
|
|
|
|
if (strlen(parentpath) == 0)
|
|
|
|
strlcpy(parentpath, ".", MAXPGPATH);
|
|
|
|
|
Unified logging system for command-line programs
This unifies the various ad hoc logging (message printing, error
printing) systems used throughout the command-line programs.
Features:
- Program name is automatically prefixed.
- Message string does not end with newline. This removes a common
source of inconsistencies and omissions.
- Additionally, a final newline is automatically stripped, simplifying
use of PQerrorMessage() etc., another common source of mistakes.
- I converted error message strings to use %m where possible.
- As a result of the above several points, more translatable message
strings can be shared between different components and between
frontends and backend, without gratuitous punctuation or whitespace
differences.
- There is support for setting a "log level". This is not meant to be
user-facing, but can be used internally to implement debug or
verbose modes.
- Lazy argument evaluation, so no significant overhead if logging at
some level is disabled.
- Some color in the messages, similar to gcc and clang. Set
PG_COLOR=auto to try it out. Some colors are predefined, but can be
customized by setting PG_COLORS.
- Common files (common/, fe_utils/, etc.) can handle logging much more
simply by just using one API without worrying too much about the
context of the calling program, requiring callbacks, or having to
pass "progname" around everywhere.
- Some programs called setvbuf() to make sure that stderr is
unbuffered, even on Windows. But not all programs did that. This
is now done centrally.
Soft goals:
- Reduces vertical space use and visual complexity of error reporting
in the source code.
- Encourages more deliberate classification of messages. For example,
in some cases it wasn't clear without analyzing the surrounding code
whether a message was meant as an error or just an info.
- Concepts and terms are vaguely aligned with popular logging
frameworks such as log4j and Python logging.
This is all just about printing stuff out. Nothing affects program
flow (e.g., fatal exits). The uses are just too varied to do that.
Some existing code had wrappers that do some kind of print-and-exit,
and I adapted those.
I tried to keep the output mostly the same, but there is a lot of
historical baggage to unwind and special cases to consider, and I
might not always have succeeded. One significant change is that
pg_rewind used to write all error messages to stdout. That is now
changed to stderr.
Reviewed-by: Donald Dong <xdong@csumb.edu>
Reviewed-by: Arthur Zakirov <a.zakirov@postgrespro.ru>
Discussion: https://www.postgresql.org/message-id/flat/6a609b43-4f57-7348-6480-bd022f924310@2ndquadrant.com
2019-04-01 14:24:37 +02:00
|
|
|
if (fsync_fname(parentpath, true) != 0)
|
2016-09-29 18:00:00 +02:00
|
|
|
return -1;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* durable_rename -- rename(2) wrapper, issuing fsyncs required for durability
|
|
|
|
*
|
|
|
|
* Wrapper around rename, similar to the backend version.
|
|
|
|
*/
|
|
|
|
int
|
Unified logging system for command-line programs
This unifies the various ad hoc logging (message printing, error
printing) systems used throughout the command-line programs.
Features:
- Program name is automatically prefixed.
- Message string does not end with newline. This removes a common
source of inconsistencies and omissions.
- Additionally, a final newline is automatically stripped, simplifying
use of PQerrorMessage() etc., another common source of mistakes.
- I converted error message strings to use %m where possible.
- As a result of the above several points, more translatable message
strings can be shared between different components and between
frontends and backend, without gratuitous punctuation or whitespace
differences.
- There is support for setting a "log level". This is not meant to be
user-facing, but can be used internally to implement debug or
verbose modes.
- Lazy argument evaluation, so no significant overhead if logging at
some level is disabled.
- Some color in the messages, similar to gcc and clang. Set
PG_COLOR=auto to try it out. Some colors are predefined, but can be
customized by setting PG_COLORS.
- Common files (common/, fe_utils/, etc.) can handle logging much more
simply by just using one API without worrying too much about the
context of the calling program, requiring callbacks, or having to
pass "progname" around everywhere.
- Some programs called setvbuf() to make sure that stderr is
unbuffered, even on Windows. But not all programs did that. This
is now done centrally.
Soft goals:
- Reduces vertical space use and visual complexity of error reporting
in the source code.
- Encourages more deliberate classification of messages. For example,
in some cases it wasn't clear without analyzing the surrounding code
whether a message was meant as an error or just an info.
- Concepts and terms are vaguely aligned with popular logging
frameworks such as log4j and Python logging.
This is all just about printing stuff out. Nothing affects program
flow (e.g., fatal exits). The uses are just too varied to do that.
Some existing code had wrappers that do some kind of print-and-exit,
and I adapted those.
I tried to keep the output mostly the same, but there is a lot of
historical baggage to unwind and special cases to consider, and I
might not always have succeeded. One significant change is that
pg_rewind used to write all error messages to stdout. That is now
changed to stderr.
Reviewed-by: Donald Dong <xdong@csumb.edu>
Reviewed-by: Arthur Zakirov <a.zakirov@postgrespro.ru>
Discussion: https://www.postgresql.org/message-id/flat/6a609b43-4f57-7348-6480-bd022f924310@2ndquadrant.com
2019-04-01 14:24:37 +02:00
|
|
|
durable_rename(const char *oldfile, const char *newfile)
|
2016-09-29 18:00:00 +02:00
|
|
|
{
|
|
|
|
int fd;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* First fsync the old and target path (if it exists), to ensure that they
|
|
|
|
* are properly persistent on disk. Syncing the target file is not
|
|
|
|
* strictly necessary, but it makes it easier to reason about crashes;
|
|
|
|
* because it's then guaranteed that either source or target file exists
|
|
|
|
* after a crash.
|
|
|
|
*/
|
Unified logging system for command-line programs
This unifies the various ad hoc logging (message printing, error
printing) systems used throughout the command-line programs.
Features:
- Program name is automatically prefixed.
- Message string does not end with newline. This removes a common
source of inconsistencies and omissions.
- Additionally, a final newline is automatically stripped, simplifying
use of PQerrorMessage() etc., another common source of mistakes.
- I converted error message strings to use %m where possible.
- As a result of the above several points, more translatable message
strings can be shared between different components and between
frontends and backend, without gratuitous punctuation or whitespace
differences.
- There is support for setting a "log level". This is not meant to be
user-facing, but can be used internally to implement debug or
verbose modes.
- Lazy argument evaluation, so no significant overhead if logging at
some level is disabled.
- Some color in the messages, similar to gcc and clang. Set
PG_COLOR=auto to try it out. Some colors are predefined, but can be
customized by setting PG_COLORS.
- Common files (common/, fe_utils/, etc.) can handle logging much more
simply by just using one API without worrying too much about the
context of the calling program, requiring callbacks, or having to
pass "progname" around everywhere.
- Some programs called setvbuf() to make sure that stderr is
unbuffered, even on Windows. But not all programs did that. This
is now done centrally.
Soft goals:
- Reduces vertical space use and visual complexity of error reporting
in the source code.
- Encourages more deliberate classification of messages. For example,
in some cases it wasn't clear without analyzing the surrounding code
whether a message was meant as an error or just an info.
- Concepts and terms are vaguely aligned with popular logging
frameworks such as log4j and Python logging.
This is all just about printing stuff out. Nothing affects program
flow (e.g., fatal exits). The uses are just too varied to do that.
Some existing code had wrappers that do some kind of print-and-exit,
and I adapted those.
I tried to keep the output mostly the same, but there is a lot of
historical baggage to unwind and special cases to consider, and I
might not always have succeeded. One significant change is that
pg_rewind used to write all error messages to stdout. That is now
changed to stderr.
Reviewed-by: Donald Dong <xdong@csumb.edu>
Reviewed-by: Arthur Zakirov <a.zakirov@postgrespro.ru>
Discussion: https://www.postgresql.org/message-id/flat/6a609b43-4f57-7348-6480-bd022f924310@2ndquadrant.com
2019-04-01 14:24:37 +02:00
|
|
|
if (fsync_fname(oldfile, false) != 0)
|
2016-09-29 18:00:00 +02:00
|
|
|
return -1;
|
|
|
|
|
|
|
|
fd = open(newfile, PG_BINARY | O_RDWR, 0);
|
|
|
|
if (fd < 0)
|
|
|
|
{
|
|
|
|
if (errno != ENOENT)
|
|
|
|
{
|
Unified logging system for command-line programs
This unifies the various ad hoc logging (message printing, error
printing) systems used throughout the command-line programs.
Features:
- Program name is automatically prefixed.
- Message string does not end with newline. This removes a common
source of inconsistencies and omissions.
- Additionally, a final newline is automatically stripped, simplifying
use of PQerrorMessage() etc., another common source of mistakes.
- I converted error message strings to use %m where possible.
- As a result of the above several points, more translatable message
strings can be shared between different components and between
frontends and backend, without gratuitous punctuation or whitespace
differences.
- There is support for setting a "log level". This is not meant to be
user-facing, but can be used internally to implement debug or
verbose modes.
- Lazy argument evaluation, so no significant overhead if logging at
some level is disabled.
- Some color in the messages, similar to gcc and clang. Set
PG_COLOR=auto to try it out. Some colors are predefined, but can be
customized by setting PG_COLORS.
- Common files (common/, fe_utils/, etc.) can handle logging much more
simply by just using one API without worrying too much about the
context of the calling program, requiring callbacks, or having to
pass "progname" around everywhere.
- Some programs called setvbuf() to make sure that stderr is
unbuffered, even on Windows. But not all programs did that. This
is now done centrally.
Soft goals:
- Reduces vertical space use and visual complexity of error reporting
in the source code.
- Encourages more deliberate classification of messages. For example,
in some cases it wasn't clear without analyzing the surrounding code
whether a message was meant as an error or just an info.
- Concepts and terms are vaguely aligned with popular logging
frameworks such as log4j and Python logging.
This is all just about printing stuff out. Nothing affects program
flow (e.g., fatal exits). The uses are just too varied to do that.
Some existing code had wrappers that do some kind of print-and-exit,
and I adapted those.
I tried to keep the output mostly the same, but there is a lot of
historical baggage to unwind and special cases to consider, and I
might not always have succeeded. One significant change is that
pg_rewind used to write all error messages to stdout. That is now
changed to stderr.
Reviewed-by: Donald Dong <xdong@csumb.edu>
Reviewed-by: Arthur Zakirov <a.zakirov@postgrespro.ru>
Discussion: https://www.postgresql.org/message-id/flat/6a609b43-4f57-7348-6480-bd022f924310@2ndquadrant.com
2019-04-01 14:24:37 +02:00
|
|
|
pg_log_error("could not open file \"%s\": %m", newfile);
|
2016-09-29 18:00:00 +02:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
if (fsync(fd) != 0)
|
|
|
|
{
|
2022-04-08 20:55:14 +02:00
|
|
|
pg_log_error("could not fsync file \"%s\": %m", newfile);
|
2016-09-29 18:00:00 +02:00
|
|
|
close(fd);
|
2020-02-24 16:32:34 +01:00
|
|
|
exit(EXIT_FAILURE);
|
2016-09-29 18:00:00 +02:00
|
|
|
}
|
|
|
|
close(fd);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Time to do the real deal... */
|
|
|
|
if (rename(oldfile, newfile) != 0)
|
|
|
|
{
|
Unified logging system for command-line programs
This unifies the various ad hoc logging (message printing, error
printing) systems used throughout the command-line programs.
Features:
- Program name is automatically prefixed.
- Message string does not end with newline. This removes a common
source of inconsistencies and omissions.
- Additionally, a final newline is automatically stripped, simplifying
use of PQerrorMessage() etc., another common source of mistakes.
- I converted error message strings to use %m where possible.
- As a result of the above several points, more translatable message
strings can be shared between different components and between
frontends and backend, without gratuitous punctuation or whitespace
differences.
- There is support for setting a "log level". This is not meant to be
user-facing, but can be used internally to implement debug or
verbose modes.
- Lazy argument evaluation, so no significant overhead if logging at
some level is disabled.
- Some color in the messages, similar to gcc and clang. Set
PG_COLOR=auto to try it out. Some colors are predefined, but can be
customized by setting PG_COLORS.
- Common files (common/, fe_utils/, etc.) can handle logging much more
simply by just using one API without worrying too much about the
context of the calling program, requiring callbacks, or having to
pass "progname" around everywhere.
- Some programs called setvbuf() to make sure that stderr is
unbuffered, even on Windows. But not all programs did that. This
is now done centrally.
Soft goals:
- Reduces vertical space use and visual complexity of error reporting
in the source code.
- Encourages more deliberate classification of messages. For example,
in some cases it wasn't clear without analyzing the surrounding code
whether a message was meant as an error or just an info.
- Concepts and terms are vaguely aligned with popular logging
frameworks such as log4j and Python logging.
This is all just about printing stuff out. Nothing affects program
flow (e.g., fatal exits). The uses are just too varied to do that.
Some existing code had wrappers that do some kind of print-and-exit,
and I adapted those.
I tried to keep the output mostly the same, but there is a lot of
historical baggage to unwind and special cases to consider, and I
might not always have succeeded. One significant change is that
pg_rewind used to write all error messages to stdout. That is now
changed to stderr.
Reviewed-by: Donald Dong <xdong@csumb.edu>
Reviewed-by: Arthur Zakirov <a.zakirov@postgrespro.ru>
Discussion: https://www.postgresql.org/message-id/flat/6a609b43-4f57-7348-6480-bd022f924310@2ndquadrant.com
2019-04-01 14:24:37 +02:00
|
|
|
pg_log_error("could not rename file \"%s\" to \"%s\": %m",
|
|
|
|
oldfile, newfile);
|
2016-09-29 18:00:00 +02:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* To guarantee renaming the file is persistent, fsync the file with its
|
|
|
|
* new name, and its containing directory.
|
|
|
|
*/
|
Unified logging system for command-line programs
This unifies the various ad hoc logging (message printing, error
printing) systems used throughout the command-line programs.
Features:
- Program name is automatically prefixed.
- Message string does not end with newline. This removes a common
source of inconsistencies and omissions.
- Additionally, a final newline is automatically stripped, simplifying
use of PQerrorMessage() etc., another common source of mistakes.
- I converted error message strings to use %m where possible.
- As a result of the above several points, more translatable message
strings can be shared between different components and between
frontends and backend, without gratuitous punctuation or whitespace
differences.
- There is support for setting a "log level". This is not meant to be
user-facing, but can be used internally to implement debug or
verbose modes.
- Lazy argument evaluation, so no significant overhead if logging at
some level is disabled.
- Some color in the messages, similar to gcc and clang. Set
PG_COLOR=auto to try it out. Some colors are predefined, but can be
customized by setting PG_COLORS.
- Common files (common/, fe_utils/, etc.) can handle logging much more
simply by just using one API without worrying too much about the
context of the calling program, requiring callbacks, or having to
pass "progname" around everywhere.
- Some programs called setvbuf() to make sure that stderr is
unbuffered, even on Windows. But not all programs did that. This
is now done centrally.
Soft goals:
- Reduces vertical space use and visual complexity of error reporting
in the source code.
- Encourages more deliberate classification of messages. For example,
in some cases it wasn't clear without analyzing the surrounding code
whether a message was meant as an error or just an info.
- Concepts and terms are vaguely aligned with popular logging
frameworks such as log4j and Python logging.
This is all just about printing stuff out. Nothing affects program
flow (e.g., fatal exits). The uses are just too varied to do that.
Some existing code had wrappers that do some kind of print-and-exit,
and I adapted those.
I tried to keep the output mostly the same, but there is a lot of
historical baggage to unwind and special cases to consider, and I
might not always have succeeded. One significant change is that
pg_rewind used to write all error messages to stdout. That is now
changed to stderr.
Reviewed-by: Donald Dong <xdong@csumb.edu>
Reviewed-by: Arthur Zakirov <a.zakirov@postgrespro.ru>
Discussion: https://www.postgresql.org/message-id/flat/6a609b43-4f57-7348-6480-bd022f924310@2ndquadrant.com
2019-04-01 14:24:37 +02:00
|
|
|
if (fsync_fname(newfile, false) != 0)
|
2016-09-29 18:00:00 +02:00
|
|
|
return -1;
|
|
|
|
|
Unified logging system for command-line programs
This unifies the various ad hoc logging (message printing, error
printing) systems used throughout the command-line programs.
Features:
- Program name is automatically prefixed.
- Message string does not end with newline. This removes a common
source of inconsistencies and omissions.
- Additionally, a final newline is automatically stripped, simplifying
use of PQerrorMessage() etc., another common source of mistakes.
- I converted error message strings to use %m where possible.
- As a result of the above several points, more translatable message
strings can be shared between different components and between
frontends and backend, without gratuitous punctuation or whitespace
differences.
- There is support for setting a "log level". This is not meant to be
user-facing, but can be used internally to implement debug or
verbose modes.
- Lazy argument evaluation, so no significant overhead if logging at
some level is disabled.
- Some color in the messages, similar to gcc and clang. Set
PG_COLOR=auto to try it out. Some colors are predefined, but can be
customized by setting PG_COLORS.
- Common files (common/, fe_utils/, etc.) can handle logging much more
simply by just using one API without worrying too much about the
context of the calling program, requiring callbacks, or having to
pass "progname" around everywhere.
- Some programs called setvbuf() to make sure that stderr is
unbuffered, even on Windows. But not all programs did that. This
is now done centrally.
Soft goals:
- Reduces vertical space use and visual complexity of error reporting
in the source code.
- Encourages more deliberate classification of messages. For example,
in some cases it wasn't clear without analyzing the surrounding code
whether a message was meant as an error or just an info.
- Concepts and terms are vaguely aligned with popular logging
frameworks such as log4j and Python logging.
This is all just about printing stuff out. Nothing affects program
flow (e.g., fatal exits). The uses are just too varied to do that.
Some existing code had wrappers that do some kind of print-and-exit,
and I adapted those.
I tried to keep the output mostly the same, but there is a lot of
historical baggage to unwind and special cases to consider, and I
might not always have succeeded. One significant change is that
pg_rewind used to write all error messages to stdout. That is now
changed to stderr.
Reviewed-by: Donald Dong <xdong@csumb.edu>
Reviewed-by: Arthur Zakirov <a.zakirov@postgrespro.ru>
Discussion: https://www.postgresql.org/message-id/flat/6a609b43-4f57-7348-6480-bd022f924310@2ndquadrant.com
2019-04-01 14:24:37 +02:00
|
|
|
if (fsync_parent_path(newfile) != 0)
|
2016-09-29 18:00:00 +02:00
|
|
|
return -1;
|
|
|
|
|
|
|
|
return 0;
|
2016-09-29 18:00:00 +02:00
|
|
|
}
|
2020-09-07 08:11:46 +02:00
|
|
|
|
|
|
|
#endif /* FRONTEND */
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Return the type of a directory entry.
|
|
|
|
*
|
|
|
|
* In frontend code, elevel should be a level from logging.h; in backend code
|
|
|
|
* it should be a level from elog.h.
|
|
|
|
*/
|
|
|
|
PGFileType
|
|
|
|
get_dirent_type(const char *path,
|
|
|
|
const struct dirent *de,
|
|
|
|
bool look_through_symlinks,
|
|
|
|
int elevel)
|
|
|
|
{
|
|
|
|
PGFileType result;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Some systems tell us the type directly in the dirent struct, but that's
|
|
|
|
* a BSD and Linux extension not required by POSIX. Even when the
|
|
|
|
* interface is present, sometimes the type is unknown, depending on the
|
|
|
|
* filesystem.
|
|
|
|
*/
|
|
|
|
#if defined(DT_REG) && defined(DT_DIR) && defined(DT_LNK)
|
|
|
|
if (de->d_type == DT_REG)
|
|
|
|
result = PGFILETYPE_REG;
|
|
|
|
else if (de->d_type == DT_DIR)
|
|
|
|
result = PGFILETYPE_DIR;
|
|
|
|
else if (de->d_type == DT_LNK && !look_through_symlinks)
|
|
|
|
result = PGFILETYPE_LNK;
|
|
|
|
else
|
|
|
|
result = PGFILETYPE_UNKNOWN;
|
|
|
|
#else
|
|
|
|
result = PGFILETYPE_UNKNOWN;
|
|
|
|
#endif
|
|
|
|
|
|
|
|
if (result == PGFILETYPE_UNKNOWN)
|
|
|
|
{
|
|
|
|
struct stat fst;
|
|
|
|
int sret;
|
|
|
|
|
|
|
|
|
|
|
|
if (look_through_symlinks)
|
|
|
|
sret = stat(path, &fst);
|
|
|
|
else
|
|
|
|
sret = lstat(path, &fst);
|
|
|
|
|
|
|
|
if (sret < 0)
|
|
|
|
{
|
|
|
|
result = PGFILETYPE_ERROR;
|
|
|
|
#ifdef FRONTEND
|
2022-04-08 20:55:14 +02:00
|
|
|
pg_log_generic(elevel, PG_LOG_PRIMARY, "could not stat file \"%s\": %m", path);
|
2020-09-07 08:11:46 +02:00
|
|
|
#else
|
|
|
|
ereport(elevel,
|
|
|
|
(errcode_for_file_access(),
|
|
|
|
errmsg("could not stat file \"%s\": %m", path)));
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
else if (S_ISREG(fst.st_mode))
|
|
|
|
result = PGFILETYPE_REG;
|
|
|
|
else if (S_ISDIR(fst.st_mode))
|
|
|
|
result = PGFILETYPE_DIR;
|
|
|
|
else if (S_ISLNK(fst.st_mode))
|
|
|
|
result = PGFILETYPE_LNK;
|
|
|
|
}
|
|
|
|
|
|
|
|
return result;
|
|
|
|
}
|
2022-10-27 07:39:42 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* pg_pwritev_with_retry
|
|
|
|
*
|
|
|
|
* Convenience wrapper for pg_pwritev() that retries on partial write. If an
|
|
|
|
* error is returned, it is unspecified how much has been written.
|
|
|
|
*/
|
|
|
|
ssize_t
|
|
|
|
pg_pwritev_with_retry(int fd, const struct iovec *iov, int iovcnt, off_t offset)
|
|
|
|
{
|
|
|
|
struct iovec iov_copy[PG_IOV_MAX];
|
|
|
|
ssize_t sum = 0;
|
|
|
|
ssize_t part;
|
|
|
|
|
|
|
|
/* We'd better have space to make a copy, in case we need to retry. */
|
|
|
|
if (iovcnt > PG_IOV_MAX)
|
|
|
|
{
|
|
|
|
errno = EINVAL;
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (;;)
|
|
|
|
{
|
|
|
|
/* Write as much as we can. */
|
|
|
|
part = pg_pwritev(fd, iov, iovcnt, offset);
|
|
|
|
if (part < 0)
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
#ifdef SIMULATE_SHORT_WRITE
|
|
|
|
part = Min(part, 4096);
|
|
|
|
#endif
|
|
|
|
|
|
|
|
/* Count our progress. */
|
|
|
|
sum += part;
|
|
|
|
offset += part;
|
|
|
|
|
|
|
|
/* Step over iovecs that are done. */
|
|
|
|
while (iovcnt > 0 && iov->iov_len <= part)
|
|
|
|
{
|
|
|
|
part -= iov->iov_len;
|
|
|
|
++iov;
|
|
|
|
--iovcnt;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Are they all done? */
|
|
|
|
if (iovcnt == 0)
|
|
|
|
{
|
|
|
|
/* We don't expect the kernel to write more than requested. */
|
|
|
|
Assert(part == 0);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Move whatever's left to the front of our mutable copy and adjust
|
|
|
|
* the leading iovec.
|
|
|
|
*/
|
|
|
|
Assert(iovcnt > 0);
|
|
|
|
memmove(iov_copy, iov, sizeof(*iov) * iovcnt);
|
|
|
|
Assert(iov->iov_len > part);
|
|
|
|
iov_copy[0].iov_base = (char *) iov_copy[0].iov_base + part;
|
|
|
|
iov_copy[0].iov_len -= part;
|
|
|
|
iov = iov_copy;
|
|
|
|
}
|
|
|
|
|
|
|
|
return sum;
|
|
|
|
}
|
2022-11-08 04:23:46 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* pg_pwrite_zeros
|
|
|
|
*
|
2023-03-06 05:21:33 +01:00
|
|
|
* Writes zeros to file worth "size" bytes at "offset" (from the start of the
|
|
|
|
* file), using vectored I/O.
|
2022-11-08 04:23:46 +01:00
|
|
|
*
|
|
|
|
* Returns the total amount of data written. On failure, a negative value
|
|
|
|
* is returned with errno set.
|
|
|
|
*/
|
|
|
|
ssize_t
|
2023-03-06 05:21:33 +01:00
|
|
|
pg_pwrite_zeros(int fd, size_t size, off_t offset)
|
2022-11-08 04:23:46 +01:00
|
|
|
{
|
2023-04-08 00:38:09 +02:00
|
|
|
static const PGIOAlignedBlock zbuffer = {{0}}; /* worth BLCKSZ */
|
|
|
|
void *zerobuf_addr = unconstify(PGIOAlignedBlock *, &zbuffer)->data;
|
2022-11-08 04:23:46 +01:00
|
|
|
struct iovec iov[PG_IOV_MAX];
|
2023-03-06 05:21:33 +01:00
|
|
|
size_t remaining_size = size;
|
2022-11-08 04:23:46 +01:00
|
|
|
ssize_t total_written = 0;
|
|
|
|
|
|
|
|
/* Loop, writing as many blocks as we can for each system call. */
|
2023-03-06 05:21:33 +01:00
|
|
|
while (remaining_size > 0)
|
2022-11-08 04:23:46 +01:00
|
|
|
{
|
2023-03-06 05:21:33 +01:00
|
|
|
int iovcnt = 0;
|
|
|
|
ssize_t written;
|
2022-11-08 04:23:46 +01:00
|
|
|
|
2023-03-06 05:21:33 +01:00
|
|
|
for (; iovcnt < PG_IOV_MAX && remaining_size > 0; iovcnt++)
|
|
|
|
{
|
|
|
|
size_t this_iov_size;
|
2022-11-08 04:23:46 +01:00
|
|
|
|
2023-03-06 05:21:33 +01:00
|
|
|
iov[iovcnt].iov_base = zerobuf_addr;
|
2022-11-08 04:23:46 +01:00
|
|
|
|
2023-03-06 05:21:33 +01:00
|
|
|
if (remaining_size < BLCKSZ)
|
|
|
|
this_iov_size = remaining_size;
|
|
|
|
else
|
|
|
|
this_iov_size = BLCKSZ;
|
2022-11-08 04:23:46 +01:00
|
|
|
|
2023-03-06 05:21:33 +01:00
|
|
|
iov[iovcnt].iov_len = this_iov_size;
|
|
|
|
remaining_size -= this_iov_size;
|
|
|
|
}
|
2022-11-08 04:23:46 +01:00
|
|
|
|
|
|
|
written = pg_pwritev_with_retry(fd, iov, iovcnt, offset);
|
|
|
|
|
|
|
|
if (written < 0)
|
|
|
|
return written;
|
|
|
|
|
2023-03-06 05:21:33 +01:00
|
|
|
offset += written;
|
2022-11-08 04:23:46 +01:00
|
|
|
total_written += written;
|
|
|
|
}
|
|
|
|
|
|
|
|
Assert(total_written == size);
|
|
|
|
|
|
|
|
return total_written;
|
|
|
|
}
|