2011-01-23 12:21:23 +01:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
|
|
|
* pg_basebackup.c - receive a base backup using streaming replication protocol
|
|
|
|
*
|
|
|
|
* Author: Magnus Hagander <magnus@hagander.net>
|
|
|
|
*
|
2020-01-01 18:21:45 +01:00
|
|
|
* Portions Copyright (c) 1996-2020, PostgreSQL Global Development Group
|
2011-01-23 12:21:23 +01:00
|
|
|
*
|
|
|
|
* IDENTIFICATION
|
|
|
|
* src/bin/pg_basebackup/pg_basebackup.c
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
|
2012-12-13 13:59:13 +01:00
|
|
|
#include "postgres_fe.h"
|
2011-01-23 12:21:23 +01:00
|
|
|
|
|
|
|
#include <unistd.h>
|
|
|
|
#include <dirent.h>
|
|
|
|
#include <sys/stat.h>
|
2011-10-26 20:13:33 +02:00
|
|
|
#include <sys/wait.h>
|
2014-02-12 20:04:13 +01:00
|
|
|
#include <signal.h>
|
2013-01-05 16:54:06 +01:00
|
|
|
#include <time.h>
|
2016-09-27 06:05:21 +02:00
|
|
|
#ifdef HAVE_SYS_SELECT_H
|
|
|
|
#include <sys/select.h>
|
|
|
|
#endif
|
2011-01-23 12:21:23 +01:00
|
|
|
#ifdef HAVE_LIBZ
|
|
|
|
#include <zlib.h>
|
|
|
|
#endif
|
|
|
|
|
Make WAL segment size configurable at initdb time.
For performance reasons a larger segment size than the default 16MB
can be useful. A larger segment size has two main benefits: Firstly,
in setups using archiving, it makes it easier to write scripts that
can keep up with higher amounts of WAL, secondly, the WAL has to be
written and synced to disk less frequently.
But at the same time large segment size are disadvantageous for
smaller databases. So far the segment size had to be configured at
compile time, often making it unrealistic to choose one fitting to a
particularly load. Therefore change it to a initdb time setting.
This includes a breaking changes to the xlogreader.h API, which now
requires the current segment size to be configured. For that and
similar reasons a number of binaries had to be taught how to recognize
the current segment size.
Author: Beena Emerson, editorialized by Andres Freund
Reviewed-By: Andres Freund, David Steele, Kuntal Ghosh, Michael
Paquier, Peter Eisentraut, Robert Hass, Tushar Ahuja
Discussion: https://postgr.es/m/CAOG9ApEAcQ--1ieKbhFzXSQPw_YLmepaa4hNdnY5+ZULpt81Mw@mail.gmail.com
2017-09-20 07:03:48 +02:00
|
|
|
#include "access/xlog_internal.h"
|
2018-04-07 23:45:39 +02:00
|
|
|
#include "common/file_perm.h"
|
2016-09-29 18:00:00 +02:00
|
|
|
#include "common/file_utils.h"
|
2019-05-14 20:19:49 +02:00
|
|
|
#include "common/logging.h"
|
2015-01-03 20:51:52 +01:00
|
|
|
#include "common/string.h"
|
2019-09-25 19:35:24 +02:00
|
|
|
#include "fe_utils/recovery_gen.h"
|
2016-08-22 04:05:57 +02:00
|
|
|
#include "fe_utils/string_utils.h"
|
2011-01-23 12:21:23 +01:00
|
|
|
#include "getopt_long.h"
|
2014-02-27 22:55:57 +01:00
|
|
|
#include "libpq-fe.h"
|
|
|
|
#include "pgtar.h"
|
|
|
|
#include "pgtime.h"
|
2019-10-23 06:08:53 +02:00
|
|
|
#include "pqexpbuffer.h"
|
2011-10-26 20:13:33 +02:00
|
|
|
#include "receivelog.h"
|
2014-02-27 22:55:57 +01:00
|
|
|
#include "replication/basebackup.h"
|
2011-10-26 20:13:33 +02:00
|
|
|
#include "streamutil.h"
|
|
|
|
|
2018-04-03 13:47:16 +02:00
|
|
|
#define ERRCODE_DATA_CORRUPTED "XX001"
|
2011-01-23 12:21:23 +01:00
|
|
|
|
2014-02-22 19:38:06 +01:00
|
|
|
typedef struct TablespaceListCell
|
|
|
|
{
|
|
|
|
struct TablespaceListCell *next;
|
2014-05-06 18:12:18 +02:00
|
|
|
char old_dir[MAXPGPATH];
|
|
|
|
char new_dir[MAXPGPATH];
|
2014-02-22 19:38:06 +01:00
|
|
|
} TablespaceListCell;
|
|
|
|
|
|
|
|
typedef struct TablespaceList
|
|
|
|
{
|
|
|
|
TablespaceListCell *head;
|
|
|
|
TablespaceListCell *tail;
|
|
|
|
} TablespaceList;
|
|
|
|
|
2019-12-05 21:14:09 +01:00
|
|
|
typedef struct WriteTarState
|
|
|
|
{
|
|
|
|
int tablespacenum;
|
|
|
|
char filename[MAXPGPATH];
|
|
|
|
FILE *tarfile;
|
|
|
|
char tarhdr[512];
|
|
|
|
bool basetablespace;
|
|
|
|
bool in_tarhdr;
|
|
|
|
bool skip_file;
|
|
|
|
bool is_recovery_guc_supported;
|
|
|
|
bool is_postgresql_auto_conf;
|
|
|
|
bool found_postgresql_auto_conf;
|
|
|
|
int file_padding_len;
|
|
|
|
size_t tarhdrsz;
|
|
|
|
pgoff_t filesz;
|
|
|
|
#ifdef HAVE_LIBZ
|
|
|
|
gzFile ztarfile;
|
|
|
|
#endif
|
|
|
|
} WriteTarState;
|
|
|
|
|
|
|
|
typedef struct UnpackTarState
|
|
|
|
{
|
|
|
|
int tablespacenum;
|
|
|
|
char current_path[MAXPGPATH];
|
|
|
|
char filename[MAXPGPATH];
|
|
|
|
const char *mapped_tblspc_path;
|
|
|
|
pgoff_t current_len_left;
|
|
|
|
int current_padding;
|
|
|
|
FILE *file;
|
|
|
|
} UnpackTarState;
|
|
|
|
|
|
|
|
typedef void (*WriteDataCallback) (size_t nbytes, char *buf,
|
|
|
|
void *callback_data);
|
|
|
|
|
2016-10-20 17:24:37 +02:00
|
|
|
/*
|
|
|
|
* pg_xlog has been renamed to pg_wal in version 10. This version number
|
|
|
|
* should be compared with PQserverVersion().
|
|
|
|
*/
|
|
|
|
#define MINIMUM_VERSION_FOR_PG_WAL 100000
|
|
|
|
|
2017-01-16 13:56:43 +01:00
|
|
|
/*
|
|
|
|
* Temporary replication slots are supported from version 10.
|
|
|
|
*/
|
|
|
|
#define MINIMUM_VERSION_FOR_TEMP_SLOTS 100000
|
|
|
|
|
2017-01-09 16:03:47 +01:00
|
|
|
/*
|
|
|
|
* Different ways to include WAL
|
|
|
|
*/
|
|
|
|
typedef enum
|
|
|
|
{
|
|
|
|
NO_WAL,
|
|
|
|
FETCH_WAL,
|
|
|
|
STREAM_WAL
|
|
|
|
} IncludeWal;
|
|
|
|
|
2011-01-23 12:21:23 +01:00
|
|
|
/* Global options */
|
2013-12-16 10:27:30 +01:00
|
|
|
static char *basedir = NULL;
|
2014-02-22 19:38:06 +01:00
|
|
|
static TablespaceList tablespace_dirs = {NULL, NULL};
|
2017-08-31 04:28:36 +02:00
|
|
|
static char *xlog_dir = NULL;
|
2014-05-06 18:12:18 +02:00
|
|
|
static char format = 'p'; /* p(lain)/t(ar) */
|
2013-12-16 10:27:30 +01:00
|
|
|
static char *label = "pg_basebackup base backup";
|
2016-09-12 18:00:00 +02:00
|
|
|
static bool noclean = false;
|
2018-04-03 13:47:16 +02:00
|
|
|
static bool checksum_failure = false;
|
2014-05-06 18:12:18 +02:00
|
|
|
static bool showprogress = false;
|
|
|
|
static int verbose = 0;
|
2013-12-16 10:27:30 +01:00
|
|
|
static int compresslevel = 0;
|
2017-01-09 16:03:47 +01:00
|
|
|
static IncludeWal includewal = STREAM_WAL;
|
2014-05-06 18:12:18 +02:00
|
|
|
static bool fastcheckpoint = false;
|
|
|
|
static bool writerecoveryconf = false;
|
2016-09-29 18:00:00 +02:00
|
|
|
static bool do_sync = true;
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
static int standby_message_timeout = 10 * 1000; /* 10 sec = default */
|
2014-02-09 12:47:09 +01:00
|
|
|
static pg_time_t last_progress_report = 0;
|
2014-02-27 22:55:57 +01:00
|
|
|
static int32 maxrate = 0; /* no limit by default */
|
2017-01-16 13:56:43 +01:00
|
|
|
static char *replication_slot = NULL;
|
|
|
|
static bool temp_replication_slot = true;
|
2017-09-26 22:07:52 +02:00
|
|
|
static bool create_slot = false;
|
|
|
|
static bool no_slot = false;
|
2018-04-03 13:47:16 +02:00
|
|
|
static bool verify_checksums = true;
|
2014-02-27 22:55:57 +01:00
|
|
|
|
2016-09-12 18:00:00 +02:00
|
|
|
static bool success = false;
|
|
|
|
static bool made_new_pgdata = false;
|
|
|
|
static bool found_existing_pgdata = false;
|
|
|
|
static bool made_new_xlogdir = false;
|
|
|
|
static bool found_existing_xlogdir = false;
|
|
|
|
static bool made_tablespace_dirs = false;
|
|
|
|
static bool found_tablespace_dirs = false;
|
2011-01-23 12:21:23 +01:00
|
|
|
|
|
|
|
/* Progress counters */
|
2019-09-03 11:59:36 +02:00
|
|
|
static uint64 totalsize_kb;
|
2011-01-23 12:21:23 +01:00
|
|
|
static uint64 totaldone;
|
|
|
|
static int tablespacecount;
|
|
|
|
|
2011-10-26 20:13:33 +02:00
|
|
|
/* Pipe to communicate with background wal receiver process */
|
|
|
|
#ifndef WIN32
|
|
|
|
static int bgpipe[2] = {-1, -1};
|
|
|
|
#endif
|
2011-01-23 12:21:23 +01:00
|
|
|
|
2011-10-26 20:13:33 +02:00
|
|
|
/* Handle to child process */
|
|
|
|
static pid_t bgchild = -1;
|
2016-09-12 18:00:00 +02:00
|
|
|
static bool in_log_streamer = false;
|
2011-10-26 20:13:33 +02:00
|
|
|
|
|
|
|
/* End position for xlog streaming, empty string if unknown yet */
|
|
|
|
static XLogRecPtr xlogendptr;
|
2012-06-10 21:20:04 +02:00
|
|
|
|
2011-12-11 00:15:15 +01:00
|
|
|
#ifndef WIN32
|
2011-10-26 20:13:33 +02:00
|
|
|
static int has_xlogendptr = 0;
|
2011-12-11 00:15:15 +01:00
|
|
|
#else
|
|
|
|
static volatile LONG has_xlogendptr = 0;
|
|
|
|
#endif
|
2011-01-23 12:21:23 +01:00
|
|
|
|
2018-11-25 16:31:16 +01:00
|
|
|
/* Contents of configuration file to be generated */
|
2013-01-05 16:54:06 +01:00
|
|
|
static PQExpBuffer recoveryconfcontents = NULL;
|
|
|
|
|
2011-01-23 12:21:23 +01:00
|
|
|
/* Function headers */
|
|
|
|
static void usage(void);
|
2016-09-12 18:00:00 +02:00
|
|
|
static void verify_dir_is_empty_or_create(char *dirname, bool *created, bool *found);
|
2014-02-09 12:47:09 +01:00
|
|
|
static void progress_report(int tablespacenum, const char *filename, bool force);
|
2011-01-23 12:21:23 +01:00
|
|
|
|
|
|
|
static void ReceiveTarFile(PGconn *conn, PGresult *res, int rownum);
|
2019-12-05 21:14:09 +01:00
|
|
|
static void ReceiveTarCopyChunk(size_t r, char *copybuf, void *callback_data);
|
2011-01-23 12:21:23 +01:00
|
|
|
static void ReceiveAndUnpackTarFile(PGconn *conn, PGresult *res, int rownum);
|
2019-12-05 21:14:09 +01:00
|
|
|
static void ReceiveTarAndUnpackCopyChunk(size_t r, char *copybuf,
|
|
|
|
void *callback_data);
|
2011-03-27 22:31:41 +02:00
|
|
|
static void BaseBackup(void);
|
2011-01-23 12:21:23 +01:00
|
|
|
|
2012-07-31 16:11:11 +02:00
|
|
|
static bool reached_end_position(XLogRecPtr segendpos, uint32 timeline,
|
2019-05-22 19:04:48 +02:00
|
|
|
bool segment_finished);
|
2011-10-26 20:13:33 +02:00
|
|
|
|
2014-02-22 19:38:06 +01:00
|
|
|
static const char *get_tablespace_mapping(const char *dir);
|
|
|
|
static void tablespace_list_append(const char *arg);
|
|
|
|
|
2014-02-09 13:10:14 +01:00
|
|
|
|
2016-09-12 18:00:00 +02:00
|
|
|
static void
|
|
|
|
cleanup_directories_atexit(void)
|
|
|
|
{
|
|
|
|
if (success || in_log_streamer)
|
|
|
|
return;
|
|
|
|
|
2018-04-03 13:47:16 +02:00
|
|
|
if (!noclean && !checksum_failure)
|
2016-09-12 18:00:00 +02:00
|
|
|
{
|
|
|
|
if (made_new_pgdata)
|
|
|
|
{
|
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_info("removing data directory \"%s\"", basedir);
|
2016-09-12 18:00:00 +02:00
|
|
|
if (!rmtree(basedir, true))
|
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("failed to remove data directory");
|
2016-09-12 18:00:00 +02:00
|
|
|
}
|
|
|
|
else if (found_existing_pgdata)
|
|
|
|
{
|
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_info("removing contents of data directory \"%s\"", basedir);
|
2016-09-12 18:00:00 +02:00
|
|
|
if (!rmtree(basedir, false))
|
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("failed to remove contents of data directory");
|
2016-09-12 18:00:00 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
if (made_new_xlogdir)
|
|
|
|
{
|
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_info("removing WAL directory \"%s\"", xlog_dir);
|
2016-09-12 18:00:00 +02:00
|
|
|
if (!rmtree(xlog_dir, true))
|
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("failed to remove WAL directory");
|
2016-09-12 18:00:00 +02:00
|
|
|
}
|
|
|
|
else if (found_existing_xlogdir)
|
|
|
|
{
|
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_info("removing contents of WAL directory \"%s\"", xlog_dir);
|
2016-09-12 18:00:00 +02:00
|
|
|
if (!rmtree(xlog_dir, false))
|
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("failed to remove contents of WAL directory");
|
2016-09-12 18:00:00 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2018-04-03 13:47:16 +02:00
|
|
|
if ((made_new_pgdata || found_existing_pgdata) && !checksum_failure)
|
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_info("data directory \"%s\" not removed at user's request", basedir);
|
2016-09-12 18:00:00 +02:00
|
|
|
|
|
|
|
if (made_new_xlogdir || found_existing_xlogdir)
|
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_info("WAL directory \"%s\" not removed at user's request", xlog_dir);
|
2016-09-12 18:00:00 +02:00
|
|
|
}
|
|
|
|
|
2018-04-03 13:47:16 +02:00
|
|
|
if ((made_tablespace_dirs || found_tablespace_dirs) && !checksum_failure)
|
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_info("changes to tablespace directories will not be undone");
|
2016-09-12 18:00:00 +02:00
|
|
|
}
|
|
|
|
|
2014-05-06 18:12:18 +02:00
|
|
|
static void
|
2018-12-29 13:21:47 +01:00
|
|
|
disconnect_atexit(void)
|
2014-02-09 13:10:14 +01:00
|
|
|
{
|
|
|
|
if (conn != NULL)
|
|
|
|
PQfinish(conn);
|
2018-12-29 13:21:47 +01:00
|
|
|
}
|
2014-02-09 13:10:14 +01:00
|
|
|
|
|
|
|
#ifndef WIN32
|
2018-12-29 13:21:47 +01:00
|
|
|
/*
|
|
|
|
* On windows, our background thread dies along with the process. But on
|
|
|
|
* Unix, if we have started a subprocess, we want to kill it off so it
|
|
|
|
* doesn't remain running trying to stream data.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
kill_bgchild_atexit(void)
|
|
|
|
{
|
2014-05-06 18:12:18 +02:00
|
|
|
if (bgchild > 0)
|
2014-02-09 13:10:14 +01:00
|
|
|
kill(bgchild, SIGTERM);
|
|
|
|
}
|
2018-12-29 13:21:47 +01:00
|
|
|
#endif
|
2014-02-09 13:10:14 +01:00
|
|
|
|
2014-02-22 19:38:06 +01:00
|
|
|
/*
|
|
|
|
* Split argument into old_dir and new_dir and append to tablespace mapping
|
|
|
|
* list.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
tablespace_list_append(const char *arg)
|
|
|
|
{
|
|
|
|
TablespaceListCell *cell = (TablespaceListCell *) pg_malloc0(sizeof(TablespaceListCell));
|
2014-05-06 18:12:18 +02:00
|
|
|
char *dst;
|
|
|
|
char *dst_ptr;
|
|
|
|
const char *arg_ptr;
|
2014-02-22 19:38:06 +01:00
|
|
|
|
|
|
|
dst_ptr = dst = cell->old_dir;
|
|
|
|
for (arg_ptr = arg; *arg_ptr; arg_ptr++)
|
|
|
|
{
|
|
|
|
if (dst_ptr - dst >= 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
|
|
|
pg_log_error("directory name too long");
|
2014-02-22 19:38:06 +01:00
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (*arg_ptr == '\\' && *(arg_ptr + 1) == '=')
|
2014-05-06 18:12:18 +02:00
|
|
|
; /* skip backslash escaping = */
|
2014-02-22 19:38:06 +01:00
|
|
|
else if (*arg_ptr == '=' && (arg_ptr == arg || *(arg_ptr - 1) != '\\'))
|
|
|
|
{
|
|
|
|
if (*cell->new_dir)
|
|
|
|
{
|
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("multiple \"=\" signs in tablespace mapping");
|
2014-02-22 19:38:06 +01:00
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
dst = dst_ptr = cell->new_dir;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
*dst_ptr++ = *arg_ptr;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!*cell->old_dir || !*cell->new_dir)
|
|
|
|
{
|
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("invalid tablespace mapping format \"%s\", must be \"OLDDIR=NEWDIR\"", arg);
|
2014-02-22 19:38:06 +01:00
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
2014-05-06 18:12:18 +02:00
|
|
|
/*
|
|
|
|
* This check isn't absolutely necessary. But all tablespaces are created
|
2014-02-22 19:38:06 +01:00
|
|
|
* with absolute directories, so specifying a non-absolute path here would
|
|
|
|
* just never match, possibly confusing users. It's also good to be
|
2014-05-06 18:12:18 +02:00
|
|
|
* consistent with the new_dir check.
|
|
|
|
*/
|
2014-02-22 19:38:06 +01:00
|
|
|
if (!is_absolute_path(cell->old_dir))
|
|
|
|
{
|
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("old directory is not an absolute path in tablespace mapping: %s",
|
|
|
|
cell->old_dir);
|
2014-02-22 19:38:06 +01:00
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!is_absolute_path(cell->new_dir))
|
|
|
|
{
|
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("new directory is not an absolute path in tablespace mapping: %s",
|
|
|
|
cell->new_dir);
|
2014-02-22 19:38:06 +01:00
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
2017-11-01 15:20:05 +01:00
|
|
|
/*
|
|
|
|
* Comparisons done with these values should involve similarly
|
|
|
|
* canonicalized path values. This is particularly sensitive on Windows
|
|
|
|
* where path values may not necessarily use Unix slashes.
|
|
|
|
*/
|
2015-04-29 02:12:10 +02:00
|
|
|
canonicalize_path(cell->old_dir);
|
|
|
|
canonicalize_path(cell->new_dir);
|
|
|
|
|
2014-02-22 19:38:06 +01:00
|
|
|
if (tablespace_dirs.tail)
|
|
|
|
tablespace_dirs.tail->next = cell;
|
|
|
|
else
|
|
|
|
tablespace_dirs.head = cell;
|
|
|
|
tablespace_dirs.tail = cell;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2011-01-23 12:21:23 +01:00
|
|
|
#ifdef HAVE_LIBZ
|
|
|
|
static const char *
|
2012-03-02 21:30:01 +01:00
|
|
|
get_gz_error(gzFile gzf)
|
2011-01-23 12:21:23 +01:00
|
|
|
{
|
|
|
|
int errnum;
|
|
|
|
const char *errmsg;
|
|
|
|
|
|
|
|
errmsg = gzerror(gzf, &errnum);
|
|
|
|
if (errnum == Z_ERRNO)
|
|
|
|
return strerror(errno);
|
|
|
|
else
|
|
|
|
return errmsg;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
static void
|
|
|
|
usage(void)
|
|
|
|
{
|
2011-05-04 19:56:52 +02:00
|
|
|
printf(_("%s takes a base backup of a running PostgreSQL server.\n\n"),
|
2011-01-23 12:21:23 +01:00
|
|
|
progname);
|
|
|
|
printf(_("Usage:\n"));
|
|
|
|
printf(_(" %s [OPTION]...\n"), progname);
|
|
|
|
printf(_("\nOptions controlling the output:\n"));
|
2012-07-31 16:11:11 +02:00
|
|
|
printf(_(" -D, --pgdata=DIRECTORY receive base backup into directory\n"));
|
|
|
|
printf(_(" -F, --format=p|t output format (plain (default), tar)\n"));
|
2017-05-17 19:04:03 +02:00
|
|
|
printf(_(" -r, --max-rate=RATE maximum transfer rate to transfer data directory\n"
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
" (in kB/s, or use suffix \"k\" or \"M\")\n"));
|
2017-05-17 19:04:03 +02:00
|
|
|
printf(_(" -R, --write-recovery-conf\n"
|
2018-11-25 16:31:16 +01:00
|
|
|
" write configuration for replication\n"));
|
2017-05-17 19:04:03 +02:00
|
|
|
printf(_(" -T, --tablespace-mapping=OLDDIR=NEWDIR\n"
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
" relocate tablespace in OLDDIR to NEWDIR\n"));
|
2017-09-26 17:58:22 +02:00
|
|
|
printf(_(" --waldir=WALDIR location for the write-ahead log directory\n"));
|
2017-05-17 19:04:03 +02:00
|
|
|
printf(_(" -X, --wal-method=none|fetch|stream\n"
|
|
|
|
" include required WAL files with specified method\n"));
|
2012-07-31 16:11:11 +02:00
|
|
|
printf(_(" -z, --gzip compress tar output\n"));
|
|
|
|
printf(_(" -Z, --compress=0-9 compress tar output with given compression level\n"));
|
2011-01-23 12:21:23 +01:00
|
|
|
printf(_("\nGeneral options:\n"));
|
2017-05-17 19:04:03 +02:00
|
|
|
printf(_(" -c, --checkpoint=fast|spread\n"
|
|
|
|
" set fast or spread checkpointing\n"));
|
2017-09-26 22:07:52 +02:00
|
|
|
printf(_(" -C, --create-slot create replication slot\n"));
|
2012-07-31 16:11:11 +02:00
|
|
|
printf(_(" -l, --label=LABEL set backup label\n"));
|
2016-10-19 18:00:00 +02:00
|
|
|
printf(_(" -n, --no-clean do not clean up after errors\n"));
|
|
|
|
printf(_(" -N, --no-sync do not wait for changes to be written safely to disk\n"));
|
2012-07-31 16:11:11 +02:00
|
|
|
printf(_(" -P, --progress show progress information\n"));
|
2017-09-26 17:58:22 +02:00
|
|
|
printf(_(" -S, --slot=SLOTNAME replication slot to use\n"));
|
2012-07-31 16:11:11 +02:00
|
|
|
printf(_(" -v, --verbose output verbose messages\n"));
|
|
|
|
printf(_(" -V, --version output version information, then exit\n"));
|
2018-05-21 16:01:49 +02:00
|
|
|
printf(_(" --no-slot prevent creation of temporary replication slot\n"));
|
|
|
|
printf(_(" --no-verify-checksums\n"
|
|
|
|
" do not verify checksums\n"));
|
2012-07-31 16:11:11 +02:00
|
|
|
printf(_(" -?, --help show this help, then exit\n"));
|
2011-01-23 12:21:23 +01:00
|
|
|
printf(_("\nConnection options:\n"));
|
2013-02-25 13:48:27 +01:00
|
|
|
printf(_(" -d, --dbname=CONNSTR connection string\n"));
|
2012-07-31 16:11:11 +02:00
|
|
|
printf(_(" -h, --host=HOSTNAME database server host or socket directory\n"));
|
|
|
|
printf(_(" -p, --port=PORT database server port number\n"));
|
2017-05-17 19:04:03 +02:00
|
|
|
printf(_(" -s, --status-interval=INTERVAL\n"
|
|
|
|
" time between status packets sent to server (in seconds)\n"));
|
2012-07-31 16:11:11 +02:00
|
|
|
printf(_(" -U, --username=NAME connect as specified database user\n"));
|
|
|
|
printf(_(" -w, --no-password never prompt for password\n"));
|
|
|
|
printf(_(" -W, --password force password prompt (should happen automatically)\n"));
|
2020-02-28 08:54:49 +01:00
|
|
|
printf(_("\nReport bugs to <%s>.\n"), PACKAGE_BUGREPORT);
|
2020-02-28 08:54:49 +01:00
|
|
|
printf(_("%s home page: <%s>\n"), PACKAGE_NAME, PACKAGE_URL);
|
2011-01-23 12:21:23 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2011-10-26 20:13:33 +02:00
|
|
|
/*
|
2012-05-25 11:36:22 +02:00
|
|
|
* Called in the background process every time data is received.
|
2011-10-26 20:13:33 +02:00
|
|
|
* On Unix, we check to see if there is any data on our pipe
|
|
|
|
* (which would mean we have a stop position), and if it is, check if
|
|
|
|
* it is time to stop.
|
|
|
|
* On Windows, we are in a single process, so we can just check if it's
|
|
|
|
* time to stop.
|
|
|
|
*/
|
|
|
|
static bool
|
2012-07-31 16:11:11 +02:00
|
|
|
reached_end_position(XLogRecPtr segendpos, uint32 timeline,
|
|
|
|
bool segment_finished)
|
2011-10-26 20:13:33 +02:00
|
|
|
{
|
|
|
|
if (!has_xlogendptr)
|
|
|
|
{
|
|
|
|
#ifndef WIN32
|
|
|
|
fd_set fds;
|
|
|
|
struct timeval tv;
|
|
|
|
int r;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Don't have the end pointer yet - check our pipe to see if it has
|
|
|
|
* been sent yet.
|
|
|
|
*/
|
|
|
|
FD_ZERO(&fds);
|
|
|
|
FD_SET(bgpipe[0], &fds);
|
|
|
|
|
|
|
|
MemSet(&tv, 0, sizeof(tv));
|
|
|
|
|
|
|
|
r = select(bgpipe[0] + 1, &fds, NULL, NULL, &tv);
|
|
|
|
if (r == 1)
|
|
|
|
{
|
|
|
|
char xlogend[64];
|
2012-06-24 17:51:37 +02:00
|
|
|
uint32 hi,
|
|
|
|
lo;
|
2011-10-26 20:13:33 +02:00
|
|
|
|
|
|
|
MemSet(xlogend, 0, sizeof(xlogend));
|
2014-05-06 18:12:18 +02:00
|
|
|
r = read(bgpipe[0], xlogend, sizeof(xlogend) - 1);
|
2011-10-26 20:13:33 +02:00
|
|
|
if (r < 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 read from ready pipe: %m");
|
2011-10-26 20:13:33 +02:00
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
2012-06-24 17:51:37 +02:00
|
|
|
if (sscanf(xlogend, "%X/%X", &hi, &lo) != 2)
|
2011-10-26 20:13:33 +02:00
|
|
|
{
|
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 parse write-ahead log location \"%s\"",
|
|
|
|
xlogend);
|
2011-10-26 20:13:33 +02:00
|
|
|
exit(1);
|
|
|
|
}
|
2012-06-24 17:51:37 +02:00
|
|
|
xlogendptr = ((uint64) hi) << 32 | lo;
|
2011-10-26 20:13:33 +02:00
|
|
|
has_xlogendptr = 1;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Fall through to check if we've reached the point further
|
|
|
|
* already.
|
|
|
|
*/
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* No data received on the pipe means we don't know the end
|
|
|
|
* position yet - so just say it's not time to stop yet.
|
|
|
|
*/
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
#else
|
|
|
|
|
|
|
|
/*
|
|
|
|
* On win32, has_xlogendptr is set by the main thread, so if it's not
|
|
|
|
* set here, we just go back and wait until it shows up.
|
|
|
|
*/
|
|
|
|
return false;
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* At this point we have an end pointer, so compare it to the current
|
|
|
|
* position to figure out if it's time to stop.
|
|
|
|
*/
|
2012-06-24 17:51:37 +02:00
|
|
|
if (segendpos >= xlogendptr)
|
2011-10-26 20:13:33 +02:00
|
|
|
return true;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Have end pointer, but haven't reached it yet - so tell the caller to
|
|
|
|
* keep streaming.
|
|
|
|
*/
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
typedef struct
|
|
|
|
{
|
|
|
|
PGconn *bgconn;
|
|
|
|
XLogRecPtr startptr;
|
2016-10-23 15:16:31 +02:00
|
|
|
char xlog[MAXPGPATH]; /* directory or tarfile depending on mode */
|
2011-10-26 20:13:33 +02:00
|
|
|
char *sysidentifier;
|
|
|
|
int timeline;
|
2012-06-10 21:20:04 +02:00
|
|
|
} logstreamer_param;
|
2011-10-26 20:13:33 +02:00
|
|
|
|
|
|
|
static int
|
2012-06-10 21:20:04 +02:00
|
|
|
LogStreamerMain(logstreamer_param *param)
|
2011-10-26 20:13:33 +02:00
|
|
|
{
|
2016-03-11 11:08:01 +01:00
|
|
|
StreamCtl stream;
|
|
|
|
|
2016-09-12 18:00:00 +02:00
|
|
|
in_log_streamer = true;
|
|
|
|
|
2016-03-13 13:11:06 +01:00
|
|
|
MemSet(&stream, 0, sizeof(stream));
|
2016-03-11 11:08:01 +01:00
|
|
|
stream.startpos = param->startptr;
|
|
|
|
stream.timeline = param->timeline;
|
|
|
|
stream.sysidentifier = param->sysidentifier;
|
|
|
|
stream.stream_stop = reached_end_position;
|
2017-04-28 00:27:02 +02:00
|
|
|
#ifndef WIN32
|
|
|
|
stream.stop_socket = bgpipe[0];
|
|
|
|
#else
|
|
|
|
stream.stop_socket = PGINVALID_SOCKET;
|
|
|
|
#endif
|
2016-03-11 11:08:01 +01:00
|
|
|
stream.standby_message_timeout = standby_message_timeout;
|
|
|
|
stream.synchronous = false;
|
2019-09-04 06:21:11 +02:00
|
|
|
/* fsync happens at the end of pg_basebackup for all data */
|
|
|
|
stream.do_sync = false;
|
2016-03-11 11:08:01 +01:00
|
|
|
stream.mark_done = true;
|
|
|
|
stream.partial_suffix = NULL;
|
2017-01-16 13:56:43 +01:00
|
|
|
stream.replication_slot = replication_slot;
|
2016-03-11 11:08:01 +01:00
|
|
|
|
2016-10-23 15:16:31 +02:00
|
|
|
if (format == 'p')
|
2019-09-04 06:21:11 +02:00
|
|
|
stream.walmethod = CreateWalDirectoryMethod(param->xlog, 0,
|
|
|
|
stream.do_sync);
|
2016-10-23 15:16:31 +02:00
|
|
|
else
|
2019-09-04 06:21:11 +02:00
|
|
|
stream.walmethod = CreateWalTarMethod(param->xlog, compresslevel,
|
|
|
|
stream.do_sync);
|
2016-10-23 15:16:31 +02:00
|
|
|
|
2016-03-11 11:08:01 +01:00
|
|
|
if (!ReceiveXlogStream(param->bgconn, &stream))
|
2011-10-26 20:13:33 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Any errors will already have been reported in the function process,
|
|
|
|
* but we need to tell the parent that we didn't shutdown in a nice
|
|
|
|
* way.
|
|
|
|
*/
|
|
|
|
return 1;
|
|
|
|
|
2016-10-23 15:16:31 +02:00
|
|
|
if (!stream.walmethod->finish())
|
|
|
|
{
|
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 finish writing WAL files: %m");
|
2016-10-23 15:16:31 +02:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2011-10-26 20:13:33 +02:00
|
|
|
PQfinish(param->bgconn);
|
2016-10-25 18:57:56 +02:00
|
|
|
|
|
|
|
if (format == 'p')
|
|
|
|
FreeWalDirectoryMethod();
|
|
|
|
else
|
|
|
|
FreeWalTarMethod();
|
|
|
|
pg_free(stream.walmethod);
|
|
|
|
|
2011-10-26 20:13:33 +02:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Initiate background process for receiving xlog during the backup.
|
|
|
|
* The background stream will use its own database connection so we can
|
|
|
|
* stream the logfile in parallel with the backups.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
StartLogStreamer(char *startpos, uint32 timeline, char *sysidentifier)
|
|
|
|
{
|
|
|
|
logstreamer_param *param;
|
2012-06-24 17:51:37 +02:00
|
|
|
uint32 hi,
|
|
|
|
lo;
|
2015-01-03 20:51:52 +01:00
|
|
|
char statusdir[MAXPGPATH];
|
2011-10-26 20:13:33 +02:00
|
|
|
|
2012-10-02 21:35:10 +02:00
|
|
|
param = pg_malloc0(sizeof(logstreamer_param));
|
2011-10-26 20:13:33 +02:00
|
|
|
param->timeline = timeline;
|
|
|
|
param->sysidentifier = sysidentifier;
|
|
|
|
|
|
|
|
/* Convert the starting position */
|
2012-06-24 17:51:37 +02:00
|
|
|
if (sscanf(startpos, "%X/%X", &hi, &lo) != 2)
|
2011-10-26 20:13:33 +02:00
|
|
|
{
|
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 parse write-ahead log location \"%s\"",
|
|
|
|
startpos);
|
2018-12-29 13:21:47 +01:00
|
|
|
exit(1);
|
2011-10-26 20:13:33 +02:00
|
|
|
}
|
2012-06-24 17:51:37 +02:00
|
|
|
param->startptr = ((uint64) hi) << 32 | lo;
|
2011-10-26 20:13:33 +02:00
|
|
|
/* Round off to even segment position */
|
Make WAL segment size configurable at initdb time.
For performance reasons a larger segment size than the default 16MB
can be useful. A larger segment size has two main benefits: Firstly,
in setups using archiving, it makes it easier to write scripts that
can keep up with higher amounts of WAL, secondly, the WAL has to be
written and synced to disk less frequently.
But at the same time large segment size are disadvantageous for
smaller databases. So far the segment size had to be configured at
compile time, often making it unrealistic to choose one fitting to a
particularly load. Therefore change it to a initdb time setting.
This includes a breaking changes to the xlogreader.h API, which now
requires the current segment size to be configured. For that and
similar reasons a number of binaries had to be taught how to recognize
the current segment size.
Author: Beena Emerson, editorialized by Andres Freund
Reviewed-By: Andres Freund, David Steele, Kuntal Ghosh, Michael
Paquier, Peter Eisentraut, Robert Hass, Tushar Ahuja
Discussion: https://postgr.es/m/CAOG9ApEAcQ--1ieKbhFzXSQPw_YLmepaa4hNdnY5+ZULpt81Mw@mail.gmail.com
2017-09-20 07:03:48 +02:00
|
|
|
param->startptr -= XLogSegmentOffset(param->startptr, WalSegSz);
|
2011-10-26 20:13:33 +02:00
|
|
|
|
|
|
|
#ifndef WIN32
|
|
|
|
/* Create our background pipe */
|
2012-03-29 05:24:07 +02:00
|
|
|
if (pipe(bgpipe) < 0)
|
2011-10-26 20:13:33 +02:00
|
|
|
{
|
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 create pipe for background process: %m");
|
2018-12-29 13:21:47 +01:00
|
|
|
exit(1);
|
2011-10-26 20:13:33 +02:00
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
/* Get a second connection */
|
|
|
|
param->bgconn = GetConnection();
|
2012-05-27 11:05:24 +02:00
|
|
|
if (!param->bgconn)
|
|
|
|
/* Error message already written in GetConnection() */
|
|
|
|
exit(1);
|
2011-10-26 20:13:33 +02:00
|
|
|
|
2016-10-20 17:24:37 +02:00
|
|
|
/* In post-10 cluster, pg_xlog has been renamed to pg_wal */
|
2016-10-23 15:16:31 +02:00
|
|
|
snprintf(param->xlog, sizeof(param->xlog), "%s/%s",
|
2016-10-20 17:24:37 +02:00
|
|
|
basedir,
|
|
|
|
PQserverVersion(conn) < MINIMUM_VERSION_FOR_PG_WAL ?
|
2017-05-17 22:31:56 +02:00
|
|
|
"pg_xlog" : "pg_wal");
|
2015-01-03 20:51:52 +01:00
|
|
|
|
2017-01-16 13:56:43 +01:00
|
|
|
/* Temporary replication slots are only supported in 10 and newer */
|
|
|
|
if (PQserverVersion(conn) < MINIMUM_VERSION_FOR_TEMP_SLOTS)
|
2017-09-26 22:07:52 +02:00
|
|
|
temp_replication_slot = false;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Create replication slot if requested
|
|
|
|
*/
|
|
|
|
if (temp_replication_slot && !replication_slot)
|
|
|
|
replication_slot = psprintf("pg_basebackup_%d", (int) PQbackendPID(param->bgconn));
|
|
|
|
if (temp_replication_slot || create_slot)
|
|
|
|
{
|
|
|
|
if (!CreateReplicationSlot(param->bgconn, replication_slot, NULL,
|
|
|
|
temp_replication_slot, true, true, false))
|
2018-12-29 13:21:47 +01:00
|
|
|
exit(1);
|
2017-09-26 22:07:52 +02:00
|
|
|
|
|
|
|
if (verbose)
|
|
|
|
{
|
|
|
|
if (temp_replication_slot)
|
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_info("created temporary replication slot \"%s\"",
|
|
|
|
replication_slot);
|
2017-09-26 22:07:52 +02:00
|
|
|
else
|
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_info("created replication slot \"%s\"",
|
|
|
|
replication_slot);
|
2017-09-26 22:07:52 +02:00
|
|
|
}
|
|
|
|
}
|
2015-01-03 20:51:52 +01:00
|
|
|
|
2016-10-23 15:16:31 +02:00
|
|
|
if (format == 'p')
|
2015-01-03 20:51:52 +01:00
|
|
|
{
|
2016-10-23 15:16:31 +02:00
|
|
|
/*
|
|
|
|
* Create pg_wal/archive_status or pg_xlog/archive_status (and thus
|
2017-05-17 22:31:56 +02:00
|
|
|
* pg_wal or pg_xlog) depending on the target server so we can write
|
|
|
|
* to basedir/pg_wal or basedir/pg_xlog as the directory entry in the
|
|
|
|
* tar file may arrive later.
|
2016-10-23 15:16:31 +02:00
|
|
|
*/
|
|
|
|
snprintf(statusdir, sizeof(statusdir), "%s/%s/archive_status",
|
|
|
|
basedir,
|
|
|
|
PQserverVersion(conn) < MINIMUM_VERSION_FOR_PG_WAL ?
|
|
|
|
"pg_xlog" : "pg_wal");
|
|
|
|
|
2018-04-07 23:45:39 +02:00
|
|
|
if (pg_mkdir_p(statusdir, pg_dir_create_mode) != 0 && errno != EEXIST)
|
2016-10-23 15:16:31 +02:00
|
|
|
{
|
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 create directory \"%s\": %m", statusdir);
|
2018-12-29 13:21:47 +01:00
|
|
|
exit(1);
|
2016-10-23 15:16:31 +02:00
|
|
|
}
|
2015-01-03 20:51:52 +01:00
|
|
|
}
|
2011-10-26 20:13:33 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Start a child process and tell it to start streaming. On Unix, this is
|
|
|
|
* a fork(). On Windows, we create a thread.
|
|
|
|
*/
|
|
|
|
#ifndef WIN32
|
|
|
|
bgchild = fork();
|
|
|
|
if (bgchild == 0)
|
|
|
|
{
|
|
|
|
/* in child process */
|
|
|
|
exit(LogStreamerMain(param));
|
|
|
|
}
|
|
|
|
else if (bgchild < 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 create background process: %m");
|
2018-12-29 13:21:47 +01:00
|
|
|
exit(1);
|
2011-10-26 20:13:33 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Else we are in the parent process and all is well.
|
|
|
|
*/
|
2018-12-29 13:21:47 +01:00
|
|
|
atexit(kill_bgchild_atexit);
|
2011-10-26 20:13:33 +02:00
|
|
|
#else /* WIN32 */
|
|
|
|
bgchild = _beginthreadex(NULL, 0, (void *) LogStreamerMain, param, 0, NULL);
|
|
|
|
if (bgchild == 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 create background thread: %m");
|
2018-12-29 13:21:47 +01:00
|
|
|
exit(1);
|
2011-10-26 20:13:33 +02:00
|
|
|
}
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
2011-01-23 12:21:23 +01:00
|
|
|
/*
|
|
|
|
* Verify that the given directory exists and is empty. If it does not
|
|
|
|
* exist, it is created. If it exists but is not empty, an error will
|
2017-05-15 11:08:02 +02:00
|
|
|
* be given and the process ended.
|
2011-01-23 12:21:23 +01:00
|
|
|
*/
|
|
|
|
static void
|
2016-09-12 18:00:00 +02:00
|
|
|
verify_dir_is_empty_or_create(char *dirname, bool *created, bool *found)
|
2011-01-23 12:21:23 +01:00
|
|
|
{
|
|
|
|
switch (pg_check_dir(dirname))
|
|
|
|
{
|
|
|
|
case 0:
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Does not exist, so create
|
|
|
|
*/
|
2018-04-07 23:45:39 +02:00
|
|
|
if (pg_mkdir_p(dirname, pg_dir_create_mode) == -1)
|
2011-01-23 12:21:23 +01:00
|
|
|
{
|
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 create directory \"%s\": %m", dirname);
|
2018-12-29 13:21:47 +01:00
|
|
|
exit(1);
|
2011-01-23 12:21:23 +01:00
|
|
|
}
|
2016-09-12 18:00:00 +02:00
|
|
|
if (created)
|
|
|
|
*created = true;
|
2011-01-23 12:21:23 +01:00
|
|
|
return;
|
|
|
|
case 1:
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Exists, empty
|
|
|
|
*/
|
2016-09-12 18:00:00 +02:00
|
|
|
if (found)
|
|
|
|
*found = true;
|
2011-01-23 12:21:23 +01:00
|
|
|
return;
|
|
|
|
case 2:
|
2013-02-17 00:52:50 +01:00
|
|
|
case 3:
|
|
|
|
case 4:
|
2011-01-23 12:21:23 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Exists, not empty
|
|
|
|
*/
|
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("directory \"%s\" exists but is not empty", dirname);
|
2018-12-29 13:21:47 +01:00
|
|
|
exit(1);
|
2011-01-23 12:21:23 +01:00
|
|
|
case -1:
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Access problem
|
|
|
|
*/
|
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 access directory \"%s\": %m", dirname);
|
2018-12-29 13:21:47 +01:00
|
|
|
exit(1);
|
2011-01-23 12:21:23 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Print a progress report based on the global variables. If verbose output
|
|
|
|
* is enabled, also print the current file name.
|
2014-02-09 12:47:09 +01:00
|
|
|
*
|
|
|
|
* Progress report is written at maximum once per second, unless the
|
|
|
|
* force parameter is set to true.
|
2011-01-23 12:21:23 +01:00
|
|
|
*/
|
|
|
|
static void
|
2014-02-09 12:47:09 +01:00
|
|
|
progress_report(int tablespacenum, const char *filename, bool force)
|
2011-01-23 12:21:23 +01:00
|
|
|
{
|
2014-02-09 12:47:09 +01:00
|
|
|
int percent;
|
2011-08-16 10:24:08 +02:00
|
|
|
char totaldone_str[32];
|
|
|
|
char totalsize_str[32];
|
2014-02-09 12:47:09 +01:00
|
|
|
pg_time_t now;
|
|
|
|
|
|
|
|
if (!showprogress)
|
|
|
|
return;
|
|
|
|
|
|
|
|
now = time(NULL);
|
|
|
|
if (now == last_progress_report && !force)
|
2014-05-06 18:12:18 +02:00
|
|
|
return; /* Max once per second */
|
2014-02-09 12:47:09 +01:00
|
|
|
|
|
|
|
last_progress_report = now;
|
2019-09-03 11:59:36 +02:00
|
|
|
percent = totalsize_kb ? (int) ((totaldone / 1024) * 100 / totalsize_kb) : 0;
|
2011-04-10 17:42:00 +02:00
|
|
|
|
2011-08-16 16:56:47 +02:00
|
|
|
/*
|
2011-10-26 23:23:33 +02:00
|
|
|
* Avoid overflowing past 100% or the full size. This may make the total
|
|
|
|
* size number change as we approach the end of the backup (the estimate
|
|
|
|
* will always be wrong if WAL is included), but that's better than having
|
|
|
|
* the done column be bigger than the total.
|
2011-08-16 16:56:47 +02:00
|
|
|
*/
|
2011-01-30 21:30:09 +01:00
|
|
|
if (percent > 100)
|
|
|
|
percent = 100;
|
2019-09-03 11:59:36 +02:00
|
|
|
if (totaldone / 1024 > totalsize_kb)
|
|
|
|
totalsize_kb = totaldone / 1024;
|
2011-01-30 21:30:09 +01:00
|
|
|
|
2011-08-16 10:24:08 +02:00
|
|
|
/*
|
2011-10-26 23:23:33 +02:00
|
|
|
* Separate step to keep platform-dependent format code out of
|
|
|
|
* translatable strings. And we only test for INT64_FORMAT availability
|
|
|
|
* in snprintf, not fprintf.
|
2011-08-16 10:24:08 +02:00
|
|
|
*/
|
2012-07-31 16:11:11 +02:00
|
|
|
snprintf(totaldone_str, sizeof(totaldone_str), INT64_FORMAT,
|
|
|
|
totaldone / 1024);
|
2019-09-03 11:59:36 +02:00
|
|
|
snprintf(totalsize_str, sizeof(totalsize_str), INT64_FORMAT, totalsize_kb);
|
2011-08-16 10:24:08 +02:00
|
|
|
|
2013-01-17 14:38:49 +01:00
|
|
|
#define VERBOSE_FILENAME_LENGTH 35
|
2011-01-23 12:21:23 +01:00
|
|
|
if (verbose)
|
2011-03-19 16:38:50 +01:00
|
|
|
{
|
2011-08-16 10:19:50 +02:00
|
|
|
if (!filename)
|
2011-03-19 16:38:50 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* No filename given, so clear the status line (used for last
|
|
|
|
* call)
|
|
|
|
*/
|
|
|
|
fprintf(stderr,
|
2013-01-17 14:43:33 +01:00
|
|
|
ngettext("%*s/%s kB (100%%), %d/%d tablespace %*s",
|
|
|
|
"%*s/%s kB (100%%), %d/%d tablespaces %*s",
|
2011-08-16 10:24:08 +02:00
|
|
|
tablespacecount),
|
2013-01-17 16:10:16 +01:00
|
|
|
(int) strlen(totalsize_str),
|
2012-07-31 16:11:11 +02:00
|
|
|
totaldone_str, totalsize_str,
|
2013-01-17 14:38:49 +01:00
|
|
|
tablespacenum, tablespacecount,
|
|
|
|
VERBOSE_FILENAME_LENGTH + 5, "");
|
2011-03-19 16:38:50 +01:00
|
|
|
else
|
2013-01-17 14:38:49 +01:00
|
|
|
{
|
2013-05-29 22:58:43 +02:00
|
|
|
bool truncate = (strlen(filename) > VERBOSE_FILENAME_LENGTH);
|
2013-01-17 14:38:49 +01:00
|
|
|
|
2011-03-19 16:38:50 +01:00
|
|
|
fprintf(stderr,
|
2013-01-17 14:43:33 +01:00
|
|
|
ngettext("%*s/%s kB (%d%%), %d/%d tablespace (%s%-*.*s)",
|
|
|
|
"%*s/%s kB (%d%%), %d/%d tablespaces (%s%-*.*s)",
|
2011-08-16 10:24:08 +02:00
|
|
|
tablespacecount),
|
2013-01-17 16:10:16 +01:00
|
|
|
(int) strlen(totalsize_str),
|
2012-07-31 16:11:11 +02:00
|
|
|
totaldone_str, totalsize_str, percent,
|
2013-01-17 14:38:49 +01:00
|
|
|
tablespacenum, tablespacecount,
|
2013-05-29 22:58:43 +02:00
|
|
|
/* Prefix with "..." if we do leading truncation */
|
2013-01-17 14:38:49 +01:00
|
|
|
truncate ? "..." : "",
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
truncate ? VERBOSE_FILENAME_LENGTH - 3 : VERBOSE_FILENAME_LENGTH,
|
|
|
|
truncate ? VERBOSE_FILENAME_LENGTH - 3 : VERBOSE_FILENAME_LENGTH,
|
2013-05-29 22:58:43 +02:00
|
|
|
/* Truncate filename at beginning if it's too long */
|
2013-01-17 14:38:49 +01:00
|
|
|
truncate ? filename + strlen(filename) - VERBOSE_FILENAME_LENGTH + 3 : filename);
|
|
|
|
}
|
2011-03-19 16:38:50 +01:00
|
|
|
}
|
2011-01-23 12:21:23 +01:00
|
|
|
else
|
2011-08-16 10:24:08 +02:00
|
|
|
fprintf(stderr,
|
2013-01-17 14:43:33 +01:00
|
|
|
ngettext("%*s/%s kB (%d%%), %d/%d tablespace",
|
|
|
|
"%*s/%s kB (%d%%), %d/%d tablespaces",
|
2011-08-16 10:24:08 +02:00
|
|
|
tablespacecount),
|
2013-01-17 16:10:16 +01:00
|
|
|
(int) strlen(totalsize_str),
|
2012-07-31 16:11:11 +02:00
|
|
|
totaldone_str, totalsize_str, percent,
|
|
|
|
tablespacenum, tablespacecount);
|
2011-08-17 09:52:35 +02:00
|
|
|
|
2017-12-01 15:21:34 +01:00
|
|
|
if (isatty(fileno(stderr)))
|
|
|
|
fprintf(stderr, "\r");
|
|
|
|
else
|
|
|
|
fprintf(stderr, "\n");
|
2011-01-23 12:21:23 +01:00
|
|
|
}
|
|
|
|
|
2014-02-27 22:55:57 +01:00
|
|
|
static int32
|
|
|
|
parse_max_rate(char *src)
|
|
|
|
{
|
|
|
|
double result;
|
|
|
|
char *after_num;
|
2014-05-06 18:12:18 +02:00
|
|
|
char *suffix = NULL;
|
2014-02-27 22:55:57 +01:00
|
|
|
|
|
|
|
errno = 0;
|
|
|
|
result = strtod(src, &after_num);
|
|
|
|
if (src == after_num)
|
|
|
|
{
|
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("transfer rate \"%s\" is not a valid value", src);
|
2014-02-27 22:55:57 +01:00
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
if (errno != 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("invalid transfer rate \"%s\": %m", src);
|
2014-02-27 22:55:57 +01:00
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (result <= 0)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Reject obviously wrong values here.
|
|
|
|
*/
|
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("transfer rate must be greater than zero");
|
2014-02-27 22:55:57 +01:00
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2014-05-06 18:12:18 +02:00
|
|
|
* Evaluate suffix, after skipping over possible whitespace. Lack of
|
|
|
|
* suffix means kilobytes.
|
2014-02-27 22:55:57 +01:00
|
|
|
*/
|
|
|
|
while (*after_num != '\0' && isspace((unsigned char) *after_num))
|
|
|
|
after_num++;
|
|
|
|
|
|
|
|
if (*after_num != '\0')
|
|
|
|
{
|
|
|
|
suffix = after_num;
|
|
|
|
if (*after_num == 'k')
|
|
|
|
{
|
|
|
|
/* kilobyte is the expected unit. */
|
|
|
|
after_num++;
|
|
|
|
}
|
|
|
|
else if (*after_num == 'M')
|
|
|
|
{
|
|
|
|
after_num++;
|
|
|
|
result *= 1024.0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* The rest can only consist of white space. */
|
|
|
|
while (*after_num != '\0' && isspace((unsigned char) *after_num))
|
|
|
|
after_num++;
|
|
|
|
|
|
|
|
if (*after_num != '\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("invalid --max-rate unit: \"%s\"", suffix);
|
2014-02-27 22:55:57 +01:00
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Valid integer? */
|
|
|
|
if ((uint64) result != (uint64) ((uint32) result))
|
|
|
|
{
|
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("transfer rate \"%s\" exceeds integer range", src);
|
2014-02-27 22:55:57 +01:00
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The range is checked on the server side too, but avoid the server
|
|
|
|
* connection if a nonsensical value was passed.
|
|
|
|
*/
|
|
|
|
if (result < MAX_RATE_LOWER || result > MAX_RATE_UPPER)
|
|
|
|
{
|
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("transfer rate \"%s\" is out of range", src);
|
2014-02-27 22:55:57 +01:00
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
|
|
|
return (int32) result;
|
|
|
|
}
|
2011-01-23 12:21:23 +01:00
|
|
|
|
2019-12-05 21:14:09 +01:00
|
|
|
/*
|
|
|
|
* Read a stream of COPY data and invoke the provided callback for each
|
|
|
|
* chunk.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
ReceiveCopyData(PGconn *conn, WriteDataCallback callback,
|
|
|
|
void *callback_data)
|
|
|
|
{
|
|
|
|
PGresult *res;
|
|
|
|
|
|
|
|
/* Get the COPY data stream. */
|
|
|
|
res = PQgetResult(conn);
|
|
|
|
if (PQresultStatus(res) != PGRES_COPY_OUT)
|
|
|
|
{
|
|
|
|
pg_log_error("could not get COPY data stream: %s",
|
|
|
|
PQerrorMessage(conn));
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
PQclear(res);
|
|
|
|
|
|
|
|
/* Loop over chunks until done. */
|
|
|
|
while (1)
|
|
|
|
{
|
|
|
|
int r;
|
|
|
|
char *copybuf;
|
|
|
|
|
|
|
|
r = PQgetCopyData(conn, ©buf, 0);
|
|
|
|
if (r == -1)
|
|
|
|
{
|
|
|
|
/* End of chunk. */
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
else if (r == -2)
|
|
|
|
{
|
|
|
|
pg_log_error("could not read COPY data: %s",
|
|
|
|
PQerrorMessage(conn));
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
|
|
|
(*callback) (r, copybuf, callback_data);
|
|
|
|
|
|
|
|
PQfreemem(copybuf);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-01-05 16:54:06 +01:00
|
|
|
/*
|
|
|
|
* Write a piece of tar data
|
|
|
|
*/
|
|
|
|
static void
|
2019-12-05 21:14:09 +01:00
|
|
|
writeTarData(WriteTarState *state, char *buf, int r)
|
2013-01-05 16:54:06 +01:00
|
|
|
{
|
|
|
|
#ifdef HAVE_LIBZ
|
2019-12-05 21:14:09 +01:00
|
|
|
if (state->ztarfile != NULL)
|
2013-01-05 16:54:06 +01:00
|
|
|
{
|
2019-12-05 21:14:09 +01:00
|
|
|
if (gzwrite(state->ztarfile, buf, r) != r)
|
2013-01-05 16:54:06 +01:00
|
|
|
{
|
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 write to compressed file \"%s\": %s",
|
2019-12-05 21:14:09 +01:00
|
|
|
state->filename, get_gz_error(state->ztarfile));
|
2018-12-29 13:21:47 +01:00
|
|
|
exit(1);
|
2013-01-05 16:54:06 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
#endif
|
|
|
|
{
|
2019-12-05 21:14:09 +01:00
|
|
|
if (fwrite(buf, r, 1, state->tarfile) != 1)
|
2013-01-05 16:54:06 +01:00
|
|
|
{
|
2019-12-05 21:14:09 +01:00
|
|
|
pg_log_error("could not write to file \"%s\": %m",
|
|
|
|
state->filename);
|
2018-12-29 13:21:47 +01:00
|
|
|
exit(1);
|
2013-01-05 16:54:06 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-01-23 12:21:23 +01:00
|
|
|
/*
|
|
|
|
* Receive a tar format file from the connection to the server, and write
|
|
|
|
* the data from this file directly into a tar file. If compression is
|
|
|
|
* enabled, the data will be compressed while written to the file.
|
|
|
|
*
|
|
|
|
* The file will be named base.tar[.gz] if it's for the main data directory
|
|
|
|
* or <tablespaceoid>.tar[.gz] if it's for another tablespace.
|
|
|
|
*
|
|
|
|
* No attempt to inspect or validate the contents of the file is done.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
ReceiveTarFile(PGconn *conn, PGresult *res, int rownum)
|
|
|
|
{
|
2019-12-05 21:14:09 +01:00
|
|
|
char zerobuf[1024];
|
|
|
|
WriteTarState state;
|
2011-01-23 12:21:23 +01:00
|
|
|
|
2019-12-05 21:14:09 +01:00
|
|
|
memset(&state, 0, sizeof(state));
|
|
|
|
state.tablespacenum = rownum;
|
|
|
|
state.basetablespace = PQgetisnull(res, rownum, 0);
|
|
|
|
state.in_tarhdr = true;
|
2011-01-23 12:21:23 +01:00
|
|
|
|
2019-03-08 02:14:03 +01:00
|
|
|
/* recovery.conf is integrated into postgresql.conf in 12 and newer */
|
2019-12-05 21:14:09 +01:00
|
|
|
if (PQserverVersion(conn) >= MINIMUM_VERSION_FOR_RECOVERY_GUC)
|
|
|
|
state.is_recovery_guc_supported = true;
|
2019-03-08 02:14:03 +01:00
|
|
|
|
2019-12-05 21:14:09 +01:00
|
|
|
if (state.basetablespace)
|
2012-07-31 16:11:11 +02:00
|
|
|
{
|
2011-01-23 12:21:23 +01:00
|
|
|
/*
|
|
|
|
* Base tablespaces
|
|
|
|
*/
|
|
|
|
if (strcmp(basedir, "-") == 0)
|
2011-05-29 00:17:37 +02:00
|
|
|
{
|
2017-07-14 15:02:53 +02:00
|
|
|
#ifdef WIN32
|
|
|
|
_setmode(fileno(stdout), _O_BINARY);
|
|
|
|
#endif
|
|
|
|
|
2011-05-29 00:17:37 +02:00
|
|
|
#ifdef HAVE_LIBZ
|
2011-06-15 19:15:05 +02:00
|
|
|
if (compresslevel != 0)
|
2011-05-29 00:17:37 +02:00
|
|
|
{
|
2020-02-04 05:56:04 +01:00
|
|
|
int fd = dup(fileno(stdout));
|
|
|
|
if (fd < 0)
|
|
|
|
{
|
|
|
|
pg_log_error("could not duplicate stdout: %m");
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
|
|
|
state.ztarfile = gzdopen(fd, "wb");
|
|
|
|
if (state.ztarfile == NULL)
|
|
|
|
{
|
|
|
|
pg_log_error("could not open output file: %m");
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
2019-12-05 21:14:09 +01:00
|
|
|
if (gzsetparams(state.ztarfile, compresslevel,
|
2012-07-31 16:11:11 +02:00
|
|
|
Z_DEFAULT_STRATEGY) != Z_OK)
|
2011-05-29 00:17:37 +02:00
|
|
|
{
|
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 set compression level %d: %s",
|
2019-12-05 21:14:09 +01:00
|
|
|
compresslevel, get_gz_error(state.ztarfile));
|
2018-12-29 13:21:47 +01:00
|
|
|
exit(1);
|
2011-05-29 00:17:37 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
#endif
|
2019-12-05 21:14:09 +01:00
|
|
|
state.tarfile = stdout;
|
|
|
|
strcpy(state.filename, "-");
|
2011-05-29 00:17:37 +02:00
|
|
|
}
|
2011-01-23 12:21:23 +01:00
|
|
|
else
|
|
|
|
{
|
|
|
|
#ifdef HAVE_LIBZ
|
2011-06-15 19:15:05 +02:00
|
|
|
if (compresslevel != 0)
|
2011-01-23 12:21:23 +01:00
|
|
|
{
|
2019-12-05 21:14:09 +01:00
|
|
|
snprintf(state.filename, sizeof(state.filename),
|
|
|
|
"%s/base.tar.gz", basedir);
|
|
|
|
state.ztarfile = gzopen(state.filename, "wb");
|
|
|
|
if (gzsetparams(state.ztarfile, compresslevel,
|
2012-07-31 16:11:11 +02:00
|
|
|
Z_DEFAULT_STRATEGY) != Z_OK)
|
2011-01-23 12:21:23 +01:00
|
|
|
{
|
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 set compression level %d: %s",
|
2019-12-05 21:14:09 +01:00
|
|
|
compresslevel, get_gz_error(state.ztarfile));
|
2018-12-29 13:21:47 +01:00
|
|
|
exit(1);
|
2011-01-23 12:21:23 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
#endif
|
|
|
|
{
|
2019-12-05 21:14:09 +01:00
|
|
|
snprintf(state.filename, sizeof(state.filename),
|
|
|
|
"%s/base.tar", basedir);
|
|
|
|
state.tarfile = fopen(state.filename, "wb");
|
2011-01-23 12:21:23 +01:00
|
|
|
}
|
|
|
|
}
|
2012-07-31 16:11:11 +02:00
|
|
|
}
|
2011-01-23 12:21:23 +01:00
|
|
|
else
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Specific tablespace
|
|
|
|
*/
|
|
|
|
#ifdef HAVE_LIBZ
|
2011-06-15 19:15:05 +02:00
|
|
|
if (compresslevel != 0)
|
2011-01-23 12:21:23 +01:00
|
|
|
{
|
2019-12-05 21:14:09 +01:00
|
|
|
snprintf(state.filename, sizeof(state.filename),
|
|
|
|
"%s/%s.tar.gz",
|
|
|
|
basedir, PQgetvalue(res, rownum, 0));
|
|
|
|
state.ztarfile = gzopen(state.filename, "wb");
|
|
|
|
if (gzsetparams(state.ztarfile, compresslevel,
|
2012-07-31 16:11:11 +02:00
|
|
|
Z_DEFAULT_STRATEGY) != Z_OK)
|
2011-01-23 12:21:23 +01:00
|
|
|
{
|
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 set compression level %d: %s",
|
2019-12-05 21:14:09 +01:00
|
|
|
compresslevel, get_gz_error(state.ztarfile));
|
2018-12-29 13:21:47 +01:00
|
|
|
exit(1);
|
2011-01-23 12:21:23 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
#endif
|
|
|
|
{
|
2019-12-05 21:14:09 +01:00
|
|
|
snprintf(state.filename, sizeof(state.filename), "%s/%s.tar",
|
|
|
|
basedir, PQgetvalue(res, rownum, 0));
|
|
|
|
state.tarfile = fopen(state.filename, "wb");
|
2011-01-23 12:21:23 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
#ifdef HAVE_LIBZ
|
2011-06-15 19:15:05 +02:00
|
|
|
if (compresslevel != 0)
|
2011-01-23 12:21:23 +01:00
|
|
|
{
|
2019-12-05 21:14:09 +01:00
|
|
|
if (!state.ztarfile)
|
2011-01-23 12:21:23 +01:00
|
|
|
{
|
|
|
|
/* Compression is in use */
|
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 create compressed file \"%s\": %s",
|
2019-12-05 21:14:09 +01:00
|
|
|
state.filename, get_gz_error(state.ztarfile));
|
2018-12-29 13:21:47 +01:00
|
|
|
exit(1);
|
2011-01-23 12:21:23 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
#endif
|
|
|
|
{
|
|
|
|
/* Either no zlib support, or zlib support but compresslevel = 0 */
|
2019-12-05 21:14:09 +01:00
|
|
|
if (!state.tarfile)
|
2011-01-23 12:21:23 +01:00
|
|
|
{
|
2019-12-05 21:14:09 +01:00
|
|
|
pg_log_error("could not create file \"%s\": %m", state.filename);
|
2018-12-29 13:21:47 +01:00
|
|
|
exit(1);
|
2011-01-23 12:21:23 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-12-05 21:14:09 +01:00
|
|
|
ReceiveCopyData(conn, ReceiveTarCopyChunk, &state);
|
|
|
|
|
2011-01-23 12:21:23 +01:00
|
|
|
/*
|
2019-12-05 21:14:09 +01:00
|
|
|
* End of copy data. If requested, and this is the base tablespace, write
|
|
|
|
* configuration file into the tarfile. When done, close the file (but not
|
|
|
|
* stdout).
|
|
|
|
*
|
|
|
|
* Also, write two completely empty blocks at the end of the tar file, as
|
|
|
|
* required by some tar programs.
|
2011-01-23 12:21:23 +01:00
|
|
|
*/
|
|
|
|
|
2019-12-05 21:14:09 +01:00
|
|
|
MemSet(zerobuf, 0, sizeof(zerobuf));
|
|
|
|
|
|
|
|
if (state.basetablespace && writerecoveryconf)
|
2011-01-23 12:21:23 +01:00
|
|
|
{
|
2019-12-05 21:14:09 +01:00
|
|
|
char header[512];
|
2011-01-23 12:21:23 +01:00
|
|
|
|
2019-12-05 21:14:09 +01:00
|
|
|
/*
|
|
|
|
* If postgresql.auto.conf has not been found in the streamed data,
|
|
|
|
* add recovery configuration to postgresql.auto.conf if recovery
|
|
|
|
* parameters are GUCs. If the instance connected to is older than
|
|
|
|
* 12, create recovery.conf with this data otherwise.
|
|
|
|
*/
|
|
|
|
if (!state.found_postgresql_auto_conf || !state.is_recovery_guc_supported)
|
2011-01-23 12:21:23 +01:00
|
|
|
{
|
2019-12-05 21:14:09 +01:00
|
|
|
int padding;
|
|
|
|
|
|
|
|
tarCreateHeader(header,
|
|
|
|
state.is_recovery_guc_supported ? "postgresql.auto.conf" : "recovery.conf",
|
|
|
|
NULL,
|
|
|
|
recoveryconfcontents->len,
|
|
|
|
pg_file_create_mode, 04000, 02000,
|
|
|
|
time(NULL));
|
|
|
|
|
|
|
|
padding = ((recoveryconfcontents->len + 511) & ~511) - recoveryconfcontents->len;
|
|
|
|
|
|
|
|
writeTarData(&state, header, sizeof(header));
|
|
|
|
writeTarData(&state, recoveryconfcontents->data,
|
|
|
|
recoveryconfcontents->len);
|
|
|
|
if (padding)
|
|
|
|
writeTarData(&state, zerobuf, padding);
|
2011-01-23 12:21:23 +01:00
|
|
|
}
|
|
|
|
|
2019-12-05 21:14:09 +01:00
|
|
|
/*
|
|
|
|
* standby.signal is supported only if recovery parameters are GUCs.
|
|
|
|
*/
|
|
|
|
if (state.is_recovery_guc_supported)
|
2011-01-23 12:21:23 +01:00
|
|
|
{
|
2019-12-05 21:14:09 +01:00
|
|
|
tarCreateHeader(header, "standby.signal", NULL,
|
|
|
|
0, /* zero-length file */
|
|
|
|
pg_file_create_mode, 04000, 02000,
|
|
|
|
time(NULL));
|
2011-01-23 12:21:23 +01:00
|
|
|
|
2019-12-05 21:14:09 +01:00
|
|
|
writeTarData(&state, header, sizeof(header));
|
|
|
|
writeTarData(&state, zerobuf, 511);
|
|
|
|
}
|
|
|
|
}
|
2013-01-05 16:54:06 +01:00
|
|
|
|
2019-12-05 21:14:09 +01:00
|
|
|
/* 2 * 512 bytes empty data at end of file */
|
|
|
|
writeTarData(&state, zerobuf, sizeof(zerobuf));
|
|
|
|
|
|
|
|
#ifdef HAVE_LIBZ
|
|
|
|
if (state.ztarfile != NULL)
|
|
|
|
{
|
|
|
|
if (gzclose(state.ztarfile) != 0)
|
|
|
|
{
|
|
|
|
pg_log_error("could not close compressed file \"%s\": %s",
|
|
|
|
state.filename, get_gz_error(state.ztarfile));
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
#endif
|
|
|
|
{
|
|
|
|
if (strcmp(basedir, "-") != 0)
|
|
|
|
{
|
|
|
|
if (fclose(state.tarfile) != 0)
|
2011-01-23 12:21:23 +01:00
|
|
|
{
|
2019-12-05 21:14:09 +01:00
|
|
|
pg_log_error("could not close file \"%s\": %m",
|
|
|
|
state.filename);
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2013-01-05 16:54:06 +01:00
|
|
|
|
2019-12-05 21:14:09 +01:00
|
|
|
progress_report(rownum, state.filename, true);
|
2018-11-25 16:31:16 +01:00
|
|
|
|
2019-12-05 21:14:09 +01:00
|
|
|
/*
|
|
|
|
* Do not sync the resulting tar file yet, all files are synced once at
|
|
|
|
* the end.
|
|
|
|
*/
|
|
|
|
}
|
2018-11-25 16:31:16 +01:00
|
|
|
|
2019-12-05 21:14:09 +01:00
|
|
|
/*
|
|
|
|
* Receive one chunk of tar-format data from the server.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
ReceiveTarCopyChunk(size_t r, char *copybuf, void *callback_data)
|
|
|
|
{
|
|
|
|
WriteTarState *state = callback_data;
|
2018-11-25 16:31:16 +01:00
|
|
|
|
2019-12-05 21:14:09 +01:00
|
|
|
if (!writerecoveryconf || !state->basetablespace)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* When not writing config file, or when not working on the base
|
|
|
|
* tablespace, we never have to look for an existing configuration
|
|
|
|
* file in the stream.
|
|
|
|
*/
|
|
|
|
writeTarData(state, copybuf, r);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Look for a config file in the existing tar stream. If it's there,
|
|
|
|
* we must skip it so we can later overwrite it with our own version
|
|
|
|
* of the file.
|
|
|
|
*
|
|
|
|
* To do this, we have to process the individual files inside the TAR
|
|
|
|
* stream. The stream consists of a header and zero or more chunks,
|
|
|
|
* all 512 bytes long. The stream from the server is broken up into
|
|
|
|
* smaller pieces, so we have to track the size of the files to find
|
|
|
|
* the next header structure.
|
|
|
|
*/
|
|
|
|
int rr = r;
|
|
|
|
int pos = 0;
|
2018-11-25 16:31:16 +01:00
|
|
|
|
2019-12-05 21:14:09 +01:00
|
|
|
while (rr > 0)
|
|
|
|
{
|
|
|
|
if (state->in_tarhdr)
|
|
|
|
{
|
2019-03-08 02:14:03 +01:00
|
|
|
/*
|
2019-12-05 21:14:09 +01:00
|
|
|
* We're currently reading a header structure inside the TAR
|
|
|
|
* stream, i.e. the file metadata.
|
2019-03-08 02:14:03 +01:00
|
|
|
*/
|
2019-12-05 21:14:09 +01:00
|
|
|
if (state->tarhdrsz < 512)
|
2019-03-08 02:14:03 +01:00
|
|
|
{
|
2019-12-05 21:14:09 +01:00
|
|
|
/*
|
|
|
|
* Copy the header structure into tarhdr in case the
|
|
|
|
* header is not aligned to 512 bytes or it's not returned
|
|
|
|
* in whole by the last PQgetCopyData call.
|
|
|
|
*/
|
|
|
|
int hdrleft;
|
|
|
|
int bytes2copy;
|
2013-01-05 16:54:06 +01:00
|
|
|
|
2019-12-05 21:14:09 +01:00
|
|
|
hdrleft = 512 - state->tarhdrsz;
|
|
|
|
bytes2copy = (rr > hdrleft ? hdrleft : rr);
|
2011-01-23 12:21:23 +01:00
|
|
|
|
2019-12-05 21:14:09 +01:00
|
|
|
memcpy(&state->tarhdr[state->tarhdrsz], copybuf + pos,
|
|
|
|
bytes2copy);
|
2013-01-05 16:54:06 +01:00
|
|
|
|
2019-12-05 21:14:09 +01:00
|
|
|
rr -= bytes2copy;
|
|
|
|
pos += bytes2copy;
|
|
|
|
state->tarhdrsz += bytes2copy;
|
2012-03-28 18:19:22 +02:00
|
|
|
}
|
2019-12-05 21:14:09 +01:00
|
|
|
else
|
2013-01-05 16:54:06 +01:00
|
|
|
{
|
|
|
|
/*
|
2019-12-05 21:14:09 +01:00
|
|
|
* We have the complete header structure in tarhdr, look
|
|
|
|
* at the file metadata: we may want append recovery info
|
|
|
|
* into postgresql.auto.conf and skip standby.signal file
|
|
|
|
* if recovery parameters are integrated as GUCs, and
|
|
|
|
* recovery.conf otherwise. In both cases we must
|
|
|
|
* calculate tar padding.
|
2013-01-05 16:54:06 +01:00
|
|
|
*/
|
2019-12-05 21:14:09 +01:00
|
|
|
if (state->is_recovery_guc_supported)
|
2013-01-05 16:54:06 +01:00
|
|
|
{
|
2019-12-05 21:14:09 +01:00
|
|
|
state->skip_file =
|
|
|
|
(strcmp(&state->tarhdr[0], "standby.signal") == 0);
|
|
|
|
state->is_postgresql_auto_conf =
|
|
|
|
(strcmp(&state->tarhdr[0], "postgresql.auto.conf") == 0);
|
2013-01-05 16:54:06 +01:00
|
|
|
}
|
|
|
|
else
|
2019-12-05 21:14:09 +01:00
|
|
|
state->skip_file =
|
|
|
|
(strcmp(&state->tarhdr[0], "recovery.conf") == 0);
|
2013-01-05 16:54:06 +01:00
|
|
|
|
2019-12-05 21:14:09 +01:00
|
|
|
state->filesz = read_tar_number(&state->tarhdr[124], 12);
|
|
|
|
state->file_padding_len =
|
|
|
|
((state->filesz + 511) & ~511) - state->filesz;
|
2018-11-25 16:31:16 +01:00
|
|
|
|
2019-12-05 21:14:09 +01:00
|
|
|
if (state->is_recovery_guc_supported &&
|
|
|
|
state->is_postgresql_auto_conf &&
|
|
|
|
writerecoveryconf)
|
|
|
|
{
|
|
|
|
/* replace tar header */
|
|
|
|
char header[512];
|
2013-01-05 16:54:06 +01:00
|
|
|
|
2019-12-05 21:14:09 +01:00
|
|
|
tarCreateHeader(header, "postgresql.auto.conf", NULL,
|
|
|
|
state->filesz + recoveryconfcontents->len,
|
|
|
|
pg_file_create_mode, 04000, 02000,
|
|
|
|
time(NULL));
|
2018-11-25 16:31:16 +01:00
|
|
|
|
2019-12-05 21:14:09 +01:00
|
|
|
writeTarData(state, header, sizeof(header));
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* copy stream with padding */
|
|
|
|
state->filesz += state->file_padding_len;
|
|
|
|
|
|
|
|
if (!state->skip_file)
|
2018-11-25 16:31:16 +01:00
|
|
|
{
|
2019-12-05 21:14:09 +01:00
|
|
|
/*
|
|
|
|
* If we're not skipping the file, write the tar
|
|
|
|
* header unmodified.
|
|
|
|
*/
|
|
|
|
writeTarData(state, state->tarhdr, 512);
|
2018-11-25 16:31:16 +01:00
|
|
|
}
|
2013-01-05 16:54:06 +01:00
|
|
|
}
|
2019-12-05 21:14:09 +01:00
|
|
|
|
|
|
|
/* Next part is the file, not the header */
|
|
|
|
state->in_tarhdr = false;
|
2013-01-05 16:54:06 +01:00
|
|
|
}
|
2019-12-05 21:14:09 +01:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* We're processing a file's contents.
|
|
|
|
*/
|
|
|
|
if (state->filesz > 0)
|
2013-01-05 16:54:06 +01:00
|
|
|
{
|
|
|
|
/*
|
2019-12-05 21:14:09 +01:00
|
|
|
* We still have data to read (and possibly write).
|
2013-01-05 16:54:06 +01:00
|
|
|
*/
|
2019-12-05 21:14:09 +01:00
|
|
|
int bytes2write;
|
2013-01-05 16:54:06 +01:00
|
|
|
|
2019-12-05 21:14:09 +01:00
|
|
|
bytes2write = (state->filesz > rr ? rr : state->filesz);
|
2013-01-05 16:54:06 +01:00
|
|
|
|
2019-12-05 21:14:09 +01:00
|
|
|
if (!state->skip_file)
|
|
|
|
writeTarData(state, copybuf + pos, bytes2write);
|
2013-01-05 16:54:06 +01:00
|
|
|
|
2019-12-05 21:14:09 +01:00
|
|
|
rr -= bytes2write;
|
|
|
|
pos += bytes2write;
|
|
|
|
state->filesz -= bytes2write;
|
|
|
|
}
|
|
|
|
else if (state->is_recovery_guc_supported &&
|
|
|
|
state->is_postgresql_auto_conf &&
|
|
|
|
writerecoveryconf)
|
|
|
|
{
|
|
|
|
/* append recovery config to postgresql.auto.conf */
|
|
|
|
int padding;
|
|
|
|
int tailsize;
|
2018-11-25 16:31:16 +01:00
|
|
|
|
2019-12-05 21:14:09 +01:00
|
|
|
tailsize = (512 - state->file_padding_len) + recoveryconfcontents->len;
|
|
|
|
padding = ((tailsize + 511) & ~511) - tailsize;
|
2018-11-25 16:31:16 +01:00
|
|
|
|
2019-12-05 21:14:09 +01:00
|
|
|
writeTarData(state, recoveryconfcontents->data,
|
|
|
|
recoveryconfcontents->len);
|
2018-11-25 16:31:16 +01:00
|
|
|
|
2019-12-05 21:14:09 +01:00
|
|
|
if (padding)
|
|
|
|
{
|
|
|
|
char zerobuf[512];
|
2018-11-25 16:31:16 +01:00
|
|
|
|
2019-12-05 21:14:09 +01:00
|
|
|
MemSet(zerobuf, 0, sizeof(zerobuf));
|
|
|
|
writeTarData(state, zerobuf, padding);
|
|
|
|
}
|
2018-11-25 16:31:16 +01:00
|
|
|
|
2019-12-05 21:14:09 +01:00
|
|
|
/* skip original file padding */
|
|
|
|
state->is_postgresql_auto_conf = false;
|
|
|
|
state->skip_file = true;
|
|
|
|
state->filesz += state->file_padding_len;
|
2018-11-25 16:31:16 +01:00
|
|
|
|
2019-12-05 21:14:09 +01:00
|
|
|
state->found_postgresql_auto_conf = true;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* No more data in the current file, the next piece of
|
|
|
|
* data (if any) will be a new file header structure.
|
|
|
|
*/
|
|
|
|
state->in_tarhdr = true;
|
|
|
|
state->skip_file = false;
|
|
|
|
state->is_postgresql_auto_conf = false;
|
|
|
|
state->tarhdrsz = 0;
|
|
|
|
state->filesz = 0;
|
2013-01-05 16:54:06 +01:00
|
|
|
}
|
2011-01-23 12:21:23 +01:00
|
|
|
}
|
|
|
|
}
|
2019-12-05 21:14:09 +01:00
|
|
|
}
|
|
|
|
totaldone += r;
|
|
|
|
progress_report(state->tablespacenum, state->filename, false);
|
2011-01-23 12:21:23 +01:00
|
|
|
}
|
|
|
|
|
2014-02-22 19:38:06 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Retrieve tablespace path, either relocated or original depending on whether
|
|
|
|
* -T was passed or not.
|
|
|
|
*/
|
|
|
|
static const char *
|
|
|
|
get_tablespace_mapping(const char *dir)
|
|
|
|
{
|
|
|
|
TablespaceListCell *cell;
|
2017-11-01 15:20:05 +01:00
|
|
|
char canon_dir[MAXPGPATH];
|
|
|
|
|
|
|
|
/* Canonicalize path for comparison consistency */
|
|
|
|
strlcpy(canon_dir, dir, sizeof(canon_dir));
|
|
|
|
canonicalize_path(canon_dir);
|
2014-02-22 19:38:06 +01:00
|
|
|
|
|
|
|
for (cell = tablespace_dirs.head; cell; cell = cell->next)
|
2017-11-01 15:20:05 +01:00
|
|
|
if (strcmp(canon_dir, cell->old_dir) == 0)
|
2014-02-22 19:38:06 +01:00
|
|
|
return cell->new_dir;
|
|
|
|
|
|
|
|
return dir;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2011-01-23 12:21:23 +01:00
|
|
|
/*
|
|
|
|
* Receive a tar format stream from the connection to the server, and unpack
|
|
|
|
* the contents of it into a directory. Only files, directories and
|
|
|
|
* symlinks are supported, no other kinds of special files.
|
|
|
|
*
|
|
|
|
* If the data is for the main data directory, it will be restored in the
|
|
|
|
* specified directory. If it's for another tablespace, it will be restored
|
2014-02-22 19:38:06 +01:00
|
|
|
* in the original or mapped directory.
|
2011-01-23 12:21:23 +01:00
|
|
|
*/
|
|
|
|
static void
|
|
|
|
ReceiveAndUnpackTarFile(PGconn *conn, PGresult *res, int rownum)
|
|
|
|
{
|
2019-12-05 21:14:09 +01:00
|
|
|
UnpackTarState state;
|
Change the way pg_basebackup's tablespace mapping is implemented.
Previously, we would first create the symlinks the way they are in the
original system, and at the end replace them with the mapped symlinks.
That never really made much sense, so now we create the symlink pointing
to the correct location to begin with, so that there's no need to fix
them at the end.
The old coding didn't work correctly on Windows, because Windows junction
points look more like directories than files, and ought to be removed with
rmdir rather than unlink. Also, it incorrectly used "%d" rather than "%u"
to print an Oid, but that's gone now.
Report and patch by Amit Kapila, with minor changes by me. Reviewed by
MauMau. Backpatch to 9.4, where the --tablespace feature was added.
2014-08-22 09:16:26 +02:00
|
|
|
bool basetablespace;
|
2019-12-05 21:14:09 +01:00
|
|
|
|
|
|
|
memset(&state, 0, sizeof(state));
|
|
|
|
state.tablespacenum = rownum;
|
2011-01-23 12:21:23 +01:00
|
|
|
|
Change the way pg_basebackup's tablespace mapping is implemented.
Previously, we would first create the symlinks the way they are in the
original system, and at the end replace them with the mapped symlinks.
That never really made much sense, so now we create the symlink pointing
to the correct location to begin with, so that there's no need to fix
them at the end.
The old coding didn't work correctly on Windows, because Windows junction
points look more like directories than files, and ought to be removed with
rmdir rather than unlink. Also, it incorrectly used "%d" rather than "%u"
to print an Oid, but that's gone now.
Report and patch by Amit Kapila, with minor changes by me. Reviewed by
MauMau. Backpatch to 9.4, where the --tablespace feature was added.
2014-08-22 09:16:26 +02:00
|
|
|
basetablespace = PQgetisnull(res, rownum, 0);
|
2013-01-05 16:54:06 +01:00
|
|
|
if (basetablespace)
|
2019-12-05 21:14:09 +01:00
|
|
|
strlcpy(state.current_path, basedir, sizeof(state.current_path));
|
2011-01-23 12:21:23 +01:00
|
|
|
else
|
2019-12-05 21:14:09 +01:00
|
|
|
strlcpy(state.current_path,
|
Change the way pg_basebackup's tablespace mapping is implemented.
Previously, we would first create the symlinks the way they are in the
original system, and at the end replace them with the mapped symlinks.
That never really made much sense, so now we create the symlink pointing
to the correct location to begin with, so that there's no need to fix
them at the end.
The old coding didn't work correctly on Windows, because Windows junction
points look more like directories than files, and ought to be removed with
rmdir rather than unlink. Also, it incorrectly used "%d" rather than "%u"
to print an Oid, but that's gone now.
Report and patch by Amit Kapila, with minor changes by me. Reviewed by
MauMau. Backpatch to 9.4, where the --tablespace feature was added.
2014-08-22 09:16:26 +02:00
|
|
|
get_tablespace_mapping(PQgetvalue(res, rownum, 1)),
|
2019-12-05 21:14:09 +01:00
|
|
|
sizeof(state.current_path));
|
2011-01-23 12:21:23 +01:00
|
|
|
|
2019-12-05 21:14:09 +01:00
|
|
|
ReceiveCopyData(conn, ReceiveTarAndUnpackCopyChunk, &state);
|
|
|
|
|
|
|
|
|
|
|
|
if (state.file)
|
|
|
|
fclose(state.file);
|
|
|
|
|
|
|
|
progress_report(rownum, state.filename, true);
|
|
|
|
|
|
|
|
if (state.file != NULL)
|
2011-01-23 12:21:23 +01:00
|
|
|
{
|
2019-12-05 21:14:09 +01:00
|
|
|
pg_log_error("COPY stream ended before last file was finished");
|
2018-12-29 13:21:47 +01:00
|
|
|
exit(1);
|
2011-01-23 12:21:23 +01:00
|
|
|
}
|
|
|
|
|
2019-12-05 21:14:09 +01:00
|
|
|
if (basetablespace && writerecoveryconf)
|
|
|
|
WriteRecoveryConfig(conn, basedir, recoveryconfcontents);
|
2011-01-23 12:21:23 +01:00
|
|
|
|
2019-12-05 21:14:09 +01:00
|
|
|
/*
|
|
|
|
* No data is synced here, everything is done for all tablespaces at the
|
|
|
|
* end.
|
|
|
|
*/
|
|
|
|
}
|
2011-01-23 12:21:23 +01:00
|
|
|
|
2019-12-05 21:14:09 +01:00
|
|
|
static void
|
|
|
|
ReceiveTarAndUnpackCopyChunk(size_t r, char *copybuf, void *callback_data)
|
|
|
|
{
|
|
|
|
UnpackTarState *state = callback_data;
|
2011-01-23 12:21:23 +01:00
|
|
|
|
2019-12-05 21:14:09 +01:00
|
|
|
if (state->file == NULL)
|
|
|
|
{
|
|
|
|
#ifndef WIN32
|
|
|
|
int filemode;
|
|
|
|
#endif
|
2011-01-23 12:21:23 +01:00
|
|
|
|
2019-12-05 21:14:09 +01:00
|
|
|
/*
|
|
|
|
* No current file, so this must be the header for a new file
|
|
|
|
*/
|
|
|
|
if (r != 512)
|
2011-01-23 12:21:23 +01:00
|
|
|
{
|
2019-12-05 21:14:09 +01:00
|
|
|
pg_log_error("invalid tar block header size: %zu", r);
|
2018-12-29 13:21:47 +01:00
|
|
|
exit(1);
|
2011-01-23 12:21:23 +01:00
|
|
|
}
|
2019-12-05 21:14:09 +01:00
|
|
|
totaldone += 512;
|
2011-01-23 12:21:23 +01:00
|
|
|
|
2019-12-05 21:14:09 +01:00
|
|
|
state->current_len_left = read_tar_number(©buf[124], 12);
|
2011-01-23 12:21:23 +01:00
|
|
|
|
2019-07-21 15:27:11 +02:00
|
|
|
#ifndef WIN32
|
2019-12-05 21:14:09 +01:00
|
|
|
/* Set permissions on the file */
|
|
|
|
filemode = read_tar_number(©buf[100], 8);
|
2019-07-21 15:27:11 +02:00
|
|
|
#endif
|
2011-01-23 12:21:23 +01:00
|
|
|
|
2019-12-05 21:14:09 +01:00
|
|
|
/*
|
|
|
|
* All files are padded up to 512 bytes
|
|
|
|
*/
|
|
|
|
state->current_padding =
|
|
|
|
((state->current_len_left + 511) & ~511) - state->current_len_left;
|
2011-01-23 12:21:23 +01:00
|
|
|
|
2019-12-05 21:14:09 +01:00
|
|
|
/*
|
|
|
|
* First part of header is zero terminated filename
|
|
|
|
*/
|
|
|
|
snprintf(state->filename, sizeof(state->filename),
|
|
|
|
"%s/%s", state->current_path, copybuf);
|
|
|
|
if (state->filename[strlen(state->filename) - 1] == '/')
|
|
|
|
{
|
2011-01-23 12:21:23 +01:00
|
|
|
/*
|
2019-12-05 21:14:09 +01:00
|
|
|
* Ends in a slash means directory or symlink to directory
|
2011-01-23 12:21:23 +01:00
|
|
|
*/
|
2019-12-05 21:14:09 +01:00
|
|
|
if (copybuf[156] == '5')
|
2011-01-23 12:21:23 +01:00
|
|
|
{
|
|
|
|
/*
|
2019-12-05 21:14:09 +01:00
|
|
|
* Directory. Remove trailing slash first.
|
2011-01-23 12:21:23 +01:00
|
|
|
*/
|
2019-12-05 21:14:09 +01:00
|
|
|
state->filename[strlen(state->filename) - 1] = '\0';
|
|
|
|
if (mkdir(state->filename, pg_dir_create_mode) != 0)
|
2011-01-23 12:21:23 +01:00
|
|
|
{
|
|
|
|
/*
|
2019-12-05 21:14:09 +01:00
|
|
|
* When streaming WAL, pg_wal (or pg_xlog for pre-9.6
|
|
|
|
* clusters) will have been created by the wal receiver
|
|
|
|
* process. Also, when the WAL directory location was
|
|
|
|
* specified, pg_wal (or pg_xlog) has already been created
|
|
|
|
* as a symbolic link before starting the actual backup.
|
|
|
|
* So just ignore creation failures on related
|
|
|
|
* directories.
|
2011-01-23 12:21:23 +01:00
|
|
|
*/
|
2019-12-05 21:14:09 +01:00
|
|
|
if (!((pg_str_endswith(state->filename, "/pg_wal") ||
|
|
|
|
pg_str_endswith(state->filename, "/pg_xlog") ||
|
|
|
|
pg_str_endswith(state->filename, "/archive_status")) &&
|
|
|
|
errno == EEXIST))
|
2011-01-23 12:21:23 +01:00
|
|
|
{
|
2019-12-05 21:14:09 +01:00
|
|
|
pg_log_error("could not create directory \"%s\": %m",
|
|
|
|
state->filename);
|
|
|
|
exit(1);
|
2011-01-23 12:21:23 +01:00
|
|
|
}
|
2019-12-05 21:14:09 +01:00
|
|
|
}
|
2011-01-23 12:21:23 +01:00
|
|
|
#ifndef WIN32
|
2019-12-05 21:14:09 +01:00
|
|
|
if (chmod(state->filename, (mode_t) filemode))
|
|
|
|
pg_log_error("could not set permissions on directory \"%s\": %m",
|
|
|
|
state->filename);
|
2011-01-23 12:21:23 +01:00
|
|
|
#endif
|
2019-12-05 21:14:09 +01:00
|
|
|
}
|
|
|
|
else if (copybuf[156] == '2')
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Symbolic link
|
|
|
|
*
|
|
|
|
* It's most likely a link in pg_tblspc directory, to the
|
|
|
|
* location of a tablespace. Apply any tablespace mapping
|
|
|
|
* given on the command line (--tablespace-mapping). (We
|
|
|
|
* blindly apply the mapping without checking that the link
|
|
|
|
* really is inside pg_tblspc. We don't expect there to be
|
|
|
|
* other symlinks in a data directory, but if there are, you
|
|
|
|
* can call it an undocumented feature that you can map them
|
|
|
|
* too.)
|
|
|
|
*/
|
|
|
|
state->filename[strlen(state->filename) - 1] = '\0'; /* Remove trailing slash */
|
Change the way pg_basebackup's tablespace mapping is implemented.
Previously, we would first create the symlinks the way they are in the
original system, and at the end replace them with the mapped symlinks.
That never really made much sense, so now we create the symlink pointing
to the correct location to begin with, so that there's no need to fix
them at the end.
The old coding didn't work correctly on Windows, because Windows junction
points look more like directories than files, and ought to be removed with
rmdir rather than unlink. Also, it incorrectly used "%d" rather than "%u"
to print an Oid, but that's gone now.
Report and patch by Amit Kapila, with minor changes by me. Reviewed by
MauMau. Backpatch to 9.4, where the --tablespace feature was added.
2014-08-22 09:16:26 +02:00
|
|
|
|
2019-12-05 21:14:09 +01:00
|
|
|
state->mapped_tblspc_path =
|
|
|
|
get_tablespace_mapping(©buf[157]);
|
|
|
|
if (symlink(state->mapped_tblspc_path, state->filename) != 0)
|
2011-01-23 12:21:23 +01:00
|
|
|
{
|
2019-12-05 21:14:09 +01:00
|
|
|
pg_log_error("could not create symbolic link from \"%s\" to \"%s\": %m",
|
|
|
|
state->filename, state->mapped_tblspc_path);
|
2018-12-29 13:21:47 +01:00
|
|
|
exit(1);
|
2011-01-23 12:21:23 +01:00
|
|
|
}
|
|
|
|
}
|
2019-12-05 21:14:09 +01:00
|
|
|
else
|
2011-01-23 12:21:23 +01:00
|
|
|
{
|
2019-12-05 21:14:09 +01:00
|
|
|
pg_log_error("unrecognized link indicator \"%c\"",
|
|
|
|
copybuf[156]);
|
2018-12-29 13:21:47 +01:00
|
|
|
exit(1);
|
2011-01-23 12:21:23 +01:00
|
|
|
}
|
2019-12-05 21:14:09 +01:00
|
|
|
return; /* directory or link handled */
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* regular file
|
|
|
|
*/
|
|
|
|
state->file = fopen(state->filename, "wb");
|
|
|
|
if (!state->file)
|
|
|
|
{
|
|
|
|
pg_log_error("could not create file \"%s\": %m", state->filename);
|
|
|
|
exit(1);
|
|
|
|
}
|
2011-01-23 12:21:23 +01:00
|
|
|
|
|
|
|
#ifndef WIN32
|
2019-12-05 21:14:09 +01:00
|
|
|
if (chmod(state->filename, (mode_t) filemode))
|
|
|
|
pg_log_error("could not set permissions on file \"%s\": %m",
|
|
|
|
state->filename);
|
2011-01-23 12:21:23 +01:00
|
|
|
#endif
|
|
|
|
|
2019-12-05 21:14:09 +01:00
|
|
|
if (state->current_len_left == 0)
|
2011-01-23 12:21:23 +01:00
|
|
|
{
|
|
|
|
/*
|
2019-12-05 21:14:09 +01:00
|
|
|
* Done with this file, next one will be a new tar header
|
2011-01-23 12:21:23 +01:00
|
|
|
*/
|
2019-12-05 21:14:09 +01:00
|
|
|
fclose(state->file);
|
|
|
|
state->file = NULL;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
} /* new file */
|
|
|
|
else
|
2011-01-23 12:21:23 +01:00
|
|
|
{
|
2019-12-05 21:14:09 +01:00
|
|
|
/*
|
|
|
|
* Continuing blocks in existing file
|
|
|
|
*/
|
|
|
|
if (state->current_len_left == 0 && r == state->current_padding)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Received the padding block for this file, ignore it and close
|
|
|
|
* the file, then move on to the next tar header.
|
|
|
|
*/
|
|
|
|
fclose(state->file);
|
|
|
|
state->file = NULL;
|
|
|
|
totaldone += r;
|
|
|
|
return;
|
|
|
|
}
|
2013-01-05 16:54:06 +01:00
|
|
|
|
2019-12-05 21:14:09 +01:00
|
|
|
if (fwrite(copybuf, r, 1, state->file) != 1)
|
|
|
|
{
|
|
|
|
pg_log_error("could not write to file \"%s\": %m", state->filename);
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
totaldone += r;
|
|
|
|
progress_report(state->tablespacenum, state->filename, false);
|
2016-09-29 18:00:00 +02:00
|
|
|
|
2019-12-05 21:14:09 +01:00
|
|
|
state->current_len_left -= r;
|
|
|
|
if (state->current_len_left == 0 && state->current_padding == 0)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Received the last block, and there is no padding to be
|
|
|
|
* expected. Close the file and move on to the next tar header.
|
|
|
|
*/
|
|
|
|
fclose(state->file);
|
|
|
|
state->file = NULL;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
} /* continuing data in existing file */
|
2013-01-05 16:54:06 +01:00
|
|
|
}
|
|
|
|
|
2011-01-23 12:21:23 +01:00
|
|
|
static void
|
2011-03-27 22:31:41 +02:00
|
|
|
BaseBackup(void)
|
2011-01-23 12:21:23 +01:00
|
|
|
{
|
|
|
|
PGresult *res;
|
2011-10-26 20:13:33 +02:00
|
|
|
char *sysidentifier;
|
2014-10-01 17:22:21 +02:00
|
|
|
TimeLineID latesttli;
|
|
|
|
TimeLineID starttli;
|
2014-02-27 22:55:57 +01:00
|
|
|
char *basebkp;
|
2011-01-23 12:21:23 +01:00
|
|
|
char escaped_label[MAXPGPATH];
|
2014-02-27 22:55:57 +01:00
|
|
|
char *maxrate_clause = NULL;
|
2011-01-23 12:21:23 +01:00
|
|
|
int i;
|
2011-02-03 13:46:23 +01:00
|
|
|
char xlogstart[64];
|
|
|
|
char xlogend[64];
|
Make pg_basebackup work with pre-9.3 servers, and add server version check.
A new 'starttli' field was added to the response of BASE_BACKUP command.
Make pg_basebackup tolerate the case that it's missing, so that it still
works with older servers.
Add an explicit check for the server version, so that you get a nicer error
message if you try to use it with a pre-9.1 server.
The streaming protocol message format changed in 9.3, so -X stream still won't
work with pre-9.3 servers. I added a version check to ReceiveXLogStream()
earlier, but write that slightly differently, so that in 9.4, it will still
work with a 9.3 server. (In 9.4, the error message needs to be adjusted to
"9.3 or above", though). Also, if the version check fails, don't retry.
2013-03-22 12:02:59 +01:00
|
|
|
int minServerMajor,
|
|
|
|
maxServerMajor;
|
2016-10-20 17:24:37 +02:00
|
|
|
int serverVersion,
|
|
|
|
serverMajor;
|
2011-01-23 12:21:23 +01:00
|
|
|
|
2016-10-20 17:24:37 +02:00
|
|
|
Assert(conn != NULL);
|
2011-01-23 12:21:23 +01:00
|
|
|
|
Make pg_basebackup work with pre-9.3 servers, and add server version check.
A new 'starttli' field was added to the response of BASE_BACKUP command.
Make pg_basebackup tolerate the case that it's missing, so that it still
works with older servers.
Add an explicit check for the server version, so that you get a nicer error
message if you try to use it with a pre-9.1 server.
The streaming protocol message format changed in 9.3, so -X stream still won't
work with pre-9.3 servers. I added a version check to ReceiveXLogStream()
earlier, but write that slightly differently, so that in 9.4, it will still
work with a 9.3 server. (In 9.4, the error message needs to be adjusted to
"9.3 or above", though). Also, if the version check fails, don't retry.
2013-03-22 12:02:59 +01:00
|
|
|
/*
|
2013-05-29 22:58:43 +02:00
|
|
|
* Check server version. BASE_BACKUP command was introduced in 9.1, so we
|
|
|
|
* can't work with servers older than 9.1.
|
Make pg_basebackup work with pre-9.3 servers, and add server version check.
A new 'starttli' field was added to the response of BASE_BACKUP command.
Make pg_basebackup tolerate the case that it's missing, so that it still
works with older servers.
Add an explicit check for the server version, so that you get a nicer error
message if you try to use it with a pre-9.1 server.
The streaming protocol message format changed in 9.3, so -X stream still won't
work with pre-9.3 servers. I added a version check to ReceiveXLogStream()
earlier, but write that slightly differently, so that in 9.4, it will still
work with a 9.3 server. (In 9.4, the error message needs to be adjusted to
"9.3 or above", though). Also, if the version check fails, don't retry.
2013-03-22 12:02:59 +01:00
|
|
|
*/
|
|
|
|
minServerMajor = 901;
|
|
|
|
maxServerMajor = PG_VERSION_NUM / 100;
|
2016-10-20 17:24:37 +02:00
|
|
|
serverVersion = PQserverVersion(conn);
|
|
|
|
serverMajor = serverVersion / 100;
|
Make pg_basebackup work with pre-9.3 servers, and add server version check.
A new 'starttli' field was added to the response of BASE_BACKUP command.
Make pg_basebackup tolerate the case that it's missing, so that it still
works with older servers.
Add an explicit check for the server version, so that you get a nicer error
message if you try to use it with a pre-9.1 server.
The streaming protocol message format changed in 9.3, so -X stream still won't
work with pre-9.3 servers. I added a version check to ReceiveXLogStream()
earlier, but write that slightly differently, so that in 9.4, it will still
work with a 9.3 server. (In 9.4, the error message needs to be adjusted to
"9.3 or above", though). Also, if the version check fails, don't retry.
2013-03-22 12:02:59 +01:00
|
|
|
if (serverMajor < minServerMajor || serverMajor > maxServerMajor)
|
|
|
|
{
|
|
|
|
const char *serverver = PQparameterStatus(conn, "server_version");
|
2013-05-29 22:58:43 +02:00
|
|
|
|
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("incompatible server version %s",
|
|
|
|
serverver ? serverver : "'unknown'");
|
2018-12-29 13:21:47 +01:00
|
|
|
exit(1);
|
Make pg_basebackup work with pre-9.3 servers, and add server version check.
A new 'starttli' field was added to the response of BASE_BACKUP command.
Make pg_basebackup tolerate the case that it's missing, so that it still
works with older servers.
Add an explicit check for the server version, so that you get a nicer error
message if you try to use it with a pre-9.1 server.
The streaming protocol message format changed in 9.3, so -X stream still won't
work with pre-9.3 servers. I added a version check to ReceiveXLogStream()
earlier, but write that slightly differently, so that in 9.4, it will still
work with a 9.3 server. (In 9.4, the error message needs to be adjusted to
"9.3 or above", though). Also, if the version check fails, don't retry.
2013-03-22 12:02:59 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If WAL streaming was requested, also check that the server is new
|
|
|
|
* enough for that.
|
|
|
|
*/
|
2017-01-09 16:03:47 +01:00
|
|
|
if (includewal == STREAM_WAL && !CheckServerVersionForStreaming(conn))
|
Make pg_basebackup work with pre-9.3 servers, and add server version check.
A new 'starttli' field was added to the response of BASE_BACKUP command.
Make pg_basebackup tolerate the case that it's missing, so that it still
works with older servers.
Add an explicit check for the server version, so that you get a nicer error
message if you try to use it with a pre-9.1 server.
The streaming protocol message format changed in 9.3, so -X stream still won't
work with pre-9.3 servers. I added a version check to ReceiveXLogStream()
earlier, but write that slightly differently, so that in 9.4, it will still
work with a 9.3 server. (In 9.4, the error message needs to be adjusted to
"9.3 or above", though). Also, if the version check fails, don't retry.
2013-03-22 12:02:59 +01:00
|
|
|
{
|
2017-01-04 10:40:38 +01:00
|
|
|
/*
|
|
|
|
* Error message already written in CheckServerVersionForStreaming(),
|
|
|
|
* but add a hint about using -X none.
|
|
|
|
*/
|
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_info("HINT: use -X none or -X fetch to disable log streaming");
|
2018-12-29 13:21:47 +01:00
|
|
|
exit(1);
|
Make pg_basebackup work with pre-9.3 servers, and add server version check.
A new 'starttli' field was added to the response of BASE_BACKUP command.
Make pg_basebackup tolerate the case that it's missing, so that it still
works with older servers.
Add an explicit check for the server version, so that you get a nicer error
message if you try to use it with a pre-9.1 server.
The streaming protocol message format changed in 9.3, so -X stream still won't
work with pre-9.3 servers. I added a version check to ReceiveXLogStream()
earlier, but write that slightly differently, so that in 9.4, it will still
work with a 9.3 server. (In 9.4, the error message needs to be adjusted to
"9.3 or above", though). Also, if the version check fails, don't retry.
2013-03-22 12:02:59 +01:00
|
|
|
}
|
|
|
|
|
2013-01-05 16:54:06 +01:00
|
|
|
/*
|
2018-11-25 16:31:16 +01:00
|
|
|
* Build contents of configuration file if requested
|
2013-01-05 16:54:06 +01:00
|
|
|
*/
|
|
|
|
if (writerecoveryconf)
|
2019-09-25 19:35:24 +02:00
|
|
|
recoveryconfcontents = GenerateRecoveryConfig(conn, replication_slot);
|
2013-01-05 16:54:06 +01:00
|
|
|
|
2011-10-26 20:13:33 +02:00
|
|
|
/*
|
|
|
|
* Run IDENTIFY_SYSTEM so we can get the timeline
|
|
|
|
*/
|
2014-10-01 17:22:21 +02:00
|
|
|
if (!RunIdentifySystem(conn, &sysidentifier, &latesttli, NULL, NULL))
|
2018-12-29 13:21:47 +01:00
|
|
|
exit(1);
|
2011-10-26 20:13:33 +02:00
|
|
|
|
2011-02-03 13:46:23 +01:00
|
|
|
/*
|
|
|
|
* Start the actual backup
|
|
|
|
*/
|
2011-01-23 12:21:23 +01:00
|
|
|
PQescapeStringConn(conn, escaped_label, label, sizeof(escaped_label), &i);
|
2014-02-27 22:55:57 +01:00
|
|
|
|
|
|
|
if (maxrate > 0)
|
|
|
|
maxrate_clause = psprintf("MAX_RATE %u", maxrate);
|
|
|
|
|
2017-02-26 21:27:51 +01:00
|
|
|
if (verbose)
|
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_info("initiating base backup, waiting for checkpoint to complete");
|
2017-02-26 21:27:51 +01:00
|
|
|
|
|
|
|
if (showprogress && !verbose)
|
2017-12-01 15:21:34 +01:00
|
|
|
{
|
|
|
|
fprintf(stderr, "waiting for checkpoint");
|
|
|
|
if (isatty(fileno(stderr)))
|
|
|
|
fprintf(stderr, "\r");
|
|
|
|
else
|
|
|
|
fprintf(stderr, "\n");
|
|
|
|
}
|
2017-02-26 21:27:51 +01:00
|
|
|
|
2014-02-27 22:55:57 +01:00
|
|
|
basebkp =
|
2018-04-03 13:47:16 +02:00
|
|
|
psprintf("BASE_BACKUP LABEL '%s' %s %s %s %s %s %s %s",
|
2014-02-27 22:55:57 +01:00
|
|
|
escaped_label,
|
|
|
|
showprogress ? "PROGRESS" : "",
|
2017-01-09 16:03:47 +01:00
|
|
|
includewal == FETCH_WAL ? "WAL" : "",
|
2014-02-27 22:55:57 +01:00
|
|
|
fastcheckpoint ? "FAST" : "",
|
2017-01-09 16:03:47 +01:00
|
|
|
includewal == NO_WAL ? "" : "NOWAIT",
|
2015-05-12 15:29:10 +02:00
|
|
|
maxrate_clause ? maxrate_clause : "",
|
2018-04-03 13:47:16 +02:00
|
|
|
format == 't' ? "TABLESPACE_MAP" : "",
|
|
|
|
verify_checksums ? "" : "NOVERIFY_CHECKSUMS");
|
2014-02-27 22:55:57 +01:00
|
|
|
|
|
|
|
if (PQsendQuery(conn, basebkp) == 0)
|
2011-01-23 12:21:23 +01:00
|
|
|
{
|
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 send replication command \"%s\": %s",
|
|
|
|
"BASE_BACKUP", PQerrorMessage(conn));
|
2018-12-29 13:21:47 +01:00
|
|
|
exit(1);
|
2011-01-23 12:21:23 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2017-05-12 19:51:27 +02:00
|
|
|
* Get the starting WAL location
|
2011-01-23 12:21:23 +01:00
|
|
|
*/
|
|
|
|
res = PQgetResult(conn);
|
|
|
|
if (PQresultStatus(res) != PGRES_TUPLES_OK)
|
|
|
|
{
|
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 initiate base backup: %s",
|
|
|
|
PQerrorMessage(conn));
|
2018-12-29 13:21:47 +01:00
|
|
|
exit(1);
|
2011-01-23 12:21:23 +01:00
|
|
|
}
|
Make pg_basebackup work with pre-9.3 servers, and add server version check.
A new 'starttli' field was added to the response of BASE_BACKUP command.
Make pg_basebackup tolerate the case that it's missing, so that it still
works with older servers.
Add an explicit check for the server version, so that you get a nicer error
message if you try to use it with a pre-9.1 server.
The streaming protocol message format changed in 9.3, so -X stream still won't
work with pre-9.3 servers. I added a version check to ReceiveXLogStream()
earlier, but write that slightly differently, so that in 9.4, it will still
work with a 9.3 server. (In 9.4, the error message needs to be adjusted to
"9.3 or above", though). Also, if the version check fails, don't retry.
2013-03-22 12:02:59 +01:00
|
|
|
if (PQntuples(res) != 1)
|
2011-02-03 13:46:23 +01:00
|
|
|
{
|
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("server returned unexpected response to BASE_BACKUP command; got %d rows and %d fields, expected %d rows and %d fields",
|
|
|
|
PQntuples(res), PQnfields(res), 1, 2);
|
2018-12-29 13:21:47 +01:00
|
|
|
exit(1);
|
2011-02-03 13:46:23 +01:00
|
|
|
}
|
Make pg_receivexlog and pg_basebackup -X stream work across timeline switches.
This mirrors the changes done earlier to the server in standby mode. When
receivelog reaches the end of a timeline, as reported by the server, it
fetches the timeline history file of the next timeline, and restarts
streaming from the new timeline by issuing a new START_STREAMING command.
When pg_receivexlog crosses a timeline, it leaves the .partial suffix on the
last segment on the old timeline. This helps you to tell apart a partial
segment left in the directory because of a timeline switch, and a completed
segment. If you just follow a single server, it won't make a difference, but
it can be significant in more complicated scenarios where new WAL is still
generated on the old timeline.
This includes two small changes to the streaming replication protocol:
First, when you reach the end of timeline while streaming, the server now
sends the TLI of the next timeline in the server's history to the client.
pg_receivexlog uses that as the next timeline, so that it doesn't need to
parse the timeline history file like a standby server does. Second, when
BASE_BACKUP command sends the begin and end WAL positions, it now also sends
the timeline IDs corresponding the positions.
2013-01-17 19:23:00 +01:00
|
|
|
|
2014-02-17 17:20:21 +01:00
|
|
|
strlcpy(xlogstart, PQgetvalue(res, 0, 0), sizeof(xlogstart));
|
2013-05-29 22:58:43 +02:00
|
|
|
|
2017-02-26 21:27:51 +01:00
|
|
|
if (verbose)
|
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_info("checkpoint completed");
|
2017-02-26 21:27:51 +01:00
|
|
|
|
Make pg_basebackup work with pre-9.3 servers, and add server version check.
A new 'starttli' field was added to the response of BASE_BACKUP command.
Make pg_basebackup tolerate the case that it's missing, so that it still
works with older servers.
Add an explicit check for the server version, so that you get a nicer error
message if you try to use it with a pre-9.1 server.
The streaming protocol message format changed in 9.3, so -X stream still won't
work with pre-9.3 servers. I added a version check to ReceiveXLogStream()
earlier, but write that slightly differently, so that in 9.4, it will still
work with a 9.3 server. (In 9.4, the error message needs to be adjusted to
"9.3 or above", though). Also, if the version check fails, don't retry.
2013-03-22 12:02:59 +01:00
|
|
|
/*
|
|
|
|
* 9.3 and later sends the TLI of the starting point. With older servers,
|
2013-05-29 22:58:43 +02:00
|
|
|
* assume it's the same as the latest timeline reported by
|
|
|
|
* IDENTIFY_SYSTEM.
|
Make pg_basebackup work with pre-9.3 servers, and add server version check.
A new 'starttli' field was added to the response of BASE_BACKUP command.
Make pg_basebackup tolerate the case that it's missing, so that it still
works with older servers.
Add an explicit check for the server version, so that you get a nicer error
message if you try to use it with a pre-9.1 server.
The streaming protocol message format changed in 9.3, so -X stream still won't
work with pre-9.3 servers. I added a version check to ReceiveXLogStream()
earlier, but write that slightly differently, so that in 9.4, it will still
work with a 9.3 server. (In 9.4, the error message needs to be adjusted to
"9.3 or above", though). Also, if the version check fails, don't retry.
2013-03-22 12:02:59 +01:00
|
|
|
*/
|
|
|
|
if (PQnfields(res) >= 2)
|
|
|
|
starttli = atoi(PQgetvalue(res, 0, 1));
|
|
|
|
else
|
|
|
|
starttli = latesttli;
|
2011-02-03 13:46:23 +01:00
|
|
|
PQclear(res);
|
|
|
|
MemSet(xlogend, 0, sizeof(xlogend));
|
|
|
|
|
2017-01-09 16:03:47 +01:00
|
|
|
if (verbose && includewal != NO_WAL)
|
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_info("write-ahead log start point: %s on timeline %u",
|
|
|
|
xlogstart, starttli);
|
Make pg_receivexlog and pg_basebackup -X stream work across timeline switches.
This mirrors the changes done earlier to the server in standby mode. When
receivelog reaches the end of a timeline, as reported by the server, it
fetches the timeline history file of the next timeline, and restarts
streaming from the new timeline by issuing a new START_STREAMING command.
When pg_receivexlog crosses a timeline, it leaves the .partial suffix on the
last segment on the old timeline. This helps you to tell apart a partial
segment left in the directory because of a timeline switch, and a completed
segment. If you just follow a single server, it won't make a difference, but
it can be significant in more complicated scenarios where new WAL is still
generated on the old timeline.
This includes two small changes to the streaming replication protocol:
First, when you reach the end of timeline while streaming, the server now
sends the TLI of the next timeline in the server's history to the client.
pg_receivexlog uses that as the next timeline, so that it doesn't need to
parse the timeline history file like a standby server does. Second, when
BASE_BACKUP command sends the begin and end WAL positions, it now also sends
the timeline IDs corresponding the positions.
2013-01-17 19:23:00 +01:00
|
|
|
|
2011-02-03 13:46:23 +01:00
|
|
|
/*
|
|
|
|
* Get the header
|
|
|
|
*/
|
|
|
|
res = PQgetResult(conn);
|
|
|
|
if (PQresultStatus(res) != PGRES_TUPLES_OK)
|
|
|
|
{
|
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 get backup header: %s",
|
|
|
|
PQerrorMessage(conn));
|
2018-12-29 13:21:47 +01:00
|
|
|
exit(1);
|
2011-02-03 13:46:23 +01:00
|
|
|
}
|
2011-01-23 12:21:23 +01:00
|
|
|
if (PQntuples(res) < 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
|
|
|
pg_log_error("no data returned from server");
|
2018-12-29 13:21:47 +01:00
|
|
|
exit(1);
|
2011-01-23 12:21:23 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Sum up the total size, for progress reporting
|
|
|
|
*/
|
2019-09-03 11:59:36 +02:00
|
|
|
totalsize_kb = totaldone = 0;
|
2011-01-23 12:21:23 +01:00
|
|
|
tablespacecount = PQntuples(res);
|
|
|
|
for (i = 0; i < PQntuples(res); i++)
|
|
|
|
{
|
2019-09-03 11:59:36 +02:00
|
|
|
totalsize_kb += atol(PQgetvalue(res, i, 2));
|
2011-01-23 12:21:23 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Verify tablespace directories are empty. Don't bother with the
|
|
|
|
* first once since it can be relocated, and it will be checked before
|
|
|
|
* we do anything anyway.
|
|
|
|
*/
|
2011-01-30 21:30:09 +01:00
|
|
|
if (format == 'p' && !PQgetisnull(res, i, 1))
|
2014-02-22 19:38:06 +01:00
|
|
|
{
|
2019-01-29 01:16:24 +01:00
|
|
|
char *path = unconstify(char *, get_tablespace_mapping(PQgetvalue(res, i, 1)));
|
2014-05-06 18:12:18 +02:00
|
|
|
|
2016-09-12 18:00:00 +02:00
|
|
|
verify_dir_is_empty_or_create(path, &made_tablespace_dirs, &found_tablespace_dirs);
|
2014-02-22 19:38:06 +01:00
|
|
|
}
|
2011-01-23 12:21:23 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* When writing to stdout, require a single tablespace
|
|
|
|
*/
|
|
|
|
if (format == 't' && strcmp(basedir, "-") == 0 && PQntuples(res) > 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
|
|
|
pg_log_error("can only write single tablespace to stdout, database has %d",
|
|
|
|
PQntuples(res));
|
2018-12-29 13:21:47 +01:00
|
|
|
exit(1);
|
2011-01-23 12:21:23 +01:00
|
|
|
}
|
|
|
|
|
2011-10-26 20:13:33 +02:00
|
|
|
/*
|
|
|
|
* If we're streaming WAL, start the streaming session before we start
|
|
|
|
* receiving the actual data chunks.
|
|
|
|
*/
|
2017-01-09 16:03:47 +01:00
|
|
|
if (includewal == STREAM_WAL)
|
2011-10-26 20:13:33 +02:00
|
|
|
{
|
|
|
|
if (verbose)
|
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_info("starting background WAL receiver");
|
Make pg_receivexlog and pg_basebackup -X stream work across timeline switches.
This mirrors the changes done earlier to the server in standby mode. When
receivelog reaches the end of a timeline, as reported by the server, it
fetches the timeline history file of the next timeline, and restarts
streaming from the new timeline by issuing a new START_STREAMING command.
When pg_receivexlog crosses a timeline, it leaves the .partial suffix on the
last segment on the old timeline. This helps you to tell apart a partial
segment left in the directory because of a timeline switch, and a completed
segment. If you just follow a single server, it won't make a difference, but
it can be significant in more complicated scenarios where new WAL is still
generated on the old timeline.
This includes two small changes to the streaming replication protocol:
First, when you reach the end of timeline while streaming, the server now
sends the TLI of the next timeline in the server's history to the client.
pg_receivexlog uses that as the next timeline, so that it doesn't need to
parse the timeline history file like a standby server does. Second, when
BASE_BACKUP command sends the begin and end WAL positions, it now also sends
the timeline IDs corresponding the positions.
2013-01-17 19:23:00 +01:00
|
|
|
StartLogStreamer(xlogstart, starttli, sysidentifier);
|
2011-10-26 20:13:33 +02:00
|
|
|
}
|
|
|
|
|
2011-01-23 12:21:23 +01:00
|
|
|
/*
|
|
|
|
* Start receiving chunks
|
|
|
|
*/
|
|
|
|
for (i = 0; i < PQntuples(res); i++)
|
|
|
|
{
|
|
|
|
if (format == 't')
|
|
|
|
ReceiveTarFile(conn, res, i);
|
|
|
|
else
|
|
|
|
ReceiveAndUnpackTarFile(conn, res, i);
|
|
|
|
} /* Loop over all tablespaces */
|
|
|
|
|
|
|
|
if (showprogress)
|
|
|
|
{
|
2014-02-09 12:47:09 +01:00
|
|
|
progress_report(PQntuples(res), NULL, true);
|
2017-12-01 15:21:34 +01:00
|
|
|
if (isatty(fileno(stderr)))
|
|
|
|
fprintf(stderr, "\n"); /* Need to move to next line */
|
2011-01-23 12:21:23 +01:00
|
|
|
}
|
2014-02-22 19:38:06 +01:00
|
|
|
|
2011-01-23 12:21:23 +01:00
|
|
|
PQclear(res);
|
|
|
|
|
2011-02-03 13:46:23 +01:00
|
|
|
/*
|
|
|
|
* Get the stop position
|
|
|
|
*/
|
|
|
|
res = PQgetResult(conn);
|
|
|
|
if (PQresultStatus(res) != PGRES_TUPLES_OK)
|
|
|
|
{
|
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 get write-ahead log end position from server: %s",
|
|
|
|
PQerrorMessage(conn));
|
2018-12-29 13:21:47 +01:00
|
|
|
exit(1);
|
2011-02-03 13:46:23 +01:00
|
|
|
}
|
|
|
|
if (PQntuples(res) != 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
|
|
|
pg_log_error("no write-ahead log end position returned from server");
|
2018-12-29 13:21:47 +01:00
|
|
|
exit(1);
|
2011-02-03 13:46:23 +01:00
|
|
|
}
|
2014-02-17 17:20:21 +01:00
|
|
|
strlcpy(xlogend, PQgetvalue(res, 0, 0), sizeof(xlogend));
|
2017-01-09 16:03:47 +01:00
|
|
|
if (verbose && includewal != NO_WAL)
|
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_info("write-ahead log end point: %s", xlogend);
|
2011-02-03 13:46:23 +01:00
|
|
|
PQclear(res);
|
|
|
|
|
2011-01-23 12:21:23 +01:00
|
|
|
res = PQgetResult(conn);
|
|
|
|
if (PQresultStatus(res) != PGRES_COMMAND_OK)
|
|
|
|
{
|
2018-04-03 13:47:16 +02:00
|
|
|
const char *sqlstate = PQresultErrorField(res, PG_DIAG_SQLSTATE);
|
|
|
|
|
|
|
|
if (sqlstate &&
|
|
|
|
strcmp(sqlstate, ERRCODE_DATA_CORRUPTED) == 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("checksum error occurred");
|
2018-04-03 13:47:16 +02:00
|
|
|
checksum_failure = true;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
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("final receive failed: %s",
|
|
|
|
PQerrorMessage(conn));
|
2018-04-03 13:47:16 +02:00
|
|
|
}
|
2018-12-29 13:21:47 +01:00
|
|
|
exit(1);
|
2011-01-23 12:21:23 +01:00
|
|
|
}
|
|
|
|
|
2011-10-26 20:13:33 +02:00
|
|
|
if (bgchild > 0)
|
|
|
|
{
|
|
|
|
#ifndef WIN32
|
2011-12-11 00:15:15 +01:00
|
|
|
int status;
|
Modernize our code for looking up descriptive strings for Unix signals.
At least as far back as the 2008 spec, POSIX has defined strsignal(3)
for looking up descriptive strings for signal numbers. We hadn't gotten
the word though, and were still using the crufty old sys_siglist array,
which is in no standard even though most Unixen provide it.
Aside from not being formally standards-compliant, this was just plain
ugly because it involved #ifdef's at every place using the code.
To eliminate the #ifdef's, create a portability function pg_strsignal,
which wraps strsignal(3) if available and otherwise falls back to
sys_siglist[] if available. The set of Unixen with neither API is
probably empty these days, but on any platform with neither, you'll
just get "unrecognized signal". All extant callers print the numeric
signal number too, so no need to work harder than that.
Along the way, upgrade pg_basebackup's child-error-exit reporting
to match the rest of the system.
Discussion: https://postgr.es/m/25758.1544983503@sss.pgh.pa.us
2018-12-17 01:38:57 +01:00
|
|
|
pid_t r;
|
2011-12-11 00:15:15 +01:00
|
|
|
#else
|
2012-06-10 21:20:04 +02:00
|
|
|
DWORD status;
|
2016-06-10 00:02:36 +02:00
|
|
|
|
2016-04-29 13:59:47 +02:00
|
|
|
/*
|
|
|
|
* get a pointer sized version of bgchild to avoid warnings about
|
|
|
|
* casting to a different size on WIN64.
|
|
|
|
*/
|
|
|
|
intptr_t bgchild_handle = bgchild;
|
2012-06-24 21:14:31 +02:00
|
|
|
uint32 hi,
|
|
|
|
lo;
|
2011-10-26 20:13:33 +02:00
|
|
|
#endif
|
|
|
|
|
|
|
|
if (verbose)
|
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_info("waiting for background process to finish streaming ...");
|
2011-10-26 20:13:33 +02:00
|
|
|
|
|
|
|
#ifndef WIN32
|
2012-03-29 05:24:07 +02:00
|
|
|
if (write(bgpipe[1], xlogend, strlen(xlogend)) != strlen(xlogend))
|
2011-10-26 20:13:33 +02:00
|
|
|
{
|
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_info("could not send command to background pipe: %m");
|
2018-12-29 13:21:47 +01:00
|
|
|
exit(1);
|
2011-10-26 20:13:33 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Just wait for the background process to exit */
|
|
|
|
r = waitpid(bgchild, &status, 0);
|
Modernize our code for looking up descriptive strings for Unix signals.
At least as far back as the 2008 spec, POSIX has defined strsignal(3)
for looking up descriptive strings for signal numbers. We hadn't gotten
the word though, and were still using the crufty old sys_siglist array,
which is in no standard even though most Unixen provide it.
Aside from not being formally standards-compliant, this was just plain
ugly because it involved #ifdef's at every place using the code.
To eliminate the #ifdef's, create a portability function pg_strsignal,
which wraps strsignal(3) if available and otherwise falls back to
sys_siglist[] if available. The set of Unixen with neither API is
probably empty these days, but on any platform with neither, you'll
just get "unrecognized signal". All extant callers print the numeric
signal number too, so no need to work harder than that.
Along the way, upgrade pg_basebackup's child-error-exit reporting
to match the rest of the system.
Discussion: https://postgr.es/m/25758.1544983503@sss.pgh.pa.us
2018-12-17 01:38:57 +01:00
|
|
|
if (r == (pid_t) -1)
|
2011-10-26 20:13:33 +02:00
|
|
|
{
|
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 wait for child process: %m");
|
2018-12-29 13:21:47 +01:00
|
|
|
exit(1);
|
2011-10-26 20:13:33 +02:00
|
|
|
}
|
|
|
|
if (r != bgchild)
|
|
|
|
{
|
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("child %d died, expected %d", (int) r, (int) bgchild);
|
2018-12-29 13:21:47 +01:00
|
|
|
exit(1);
|
2011-10-26 20:13:33 +02:00
|
|
|
}
|
Modernize our code for looking up descriptive strings for Unix signals.
At least as far back as the 2008 spec, POSIX has defined strsignal(3)
for looking up descriptive strings for signal numbers. We hadn't gotten
the word though, and were still using the crufty old sys_siglist array,
which is in no standard even though most Unixen provide it.
Aside from not being formally standards-compliant, this was just plain
ugly because it involved #ifdef's at every place using the code.
To eliminate the #ifdef's, create a portability function pg_strsignal,
which wraps strsignal(3) if available and otherwise falls back to
sys_siglist[] if available. The set of Unixen with neither API is
probably empty these days, but on any platform with neither, you'll
just get "unrecognized signal". All extant callers print the numeric
signal number too, so no need to work harder than that.
Along the way, upgrade pg_basebackup's child-error-exit reporting
to match the rest of the system.
Discussion: https://postgr.es/m/25758.1544983503@sss.pgh.pa.us
2018-12-17 01:38:57 +01:00
|
|
|
if (status != 0)
|
2011-10-26 20:13:33 +02:00
|
|
|
{
|
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("%s", wait_result_to_str(status));
|
2018-12-29 13:21:47 +01:00
|
|
|
exit(1);
|
2011-10-26 20:13:33 +02:00
|
|
|
}
|
|
|
|
/* Exited normally, we're happy! */
|
|
|
|
#else /* WIN32 */
|
|
|
|
|
|
|
|
/*
|
|
|
|
* On Windows, since we are in the same process, we can just store the
|
|
|
|
* value directly in the variable, and then set the flag that says
|
|
|
|
* it's there.
|
|
|
|
*/
|
2012-06-24 21:14:31 +02:00
|
|
|
if (sscanf(xlogend, "%X/%X", &hi, &lo) != 2)
|
2011-10-26 20:13:33 +02:00
|
|
|
{
|
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 parse write-ahead log location \"%s\"",
|
|
|
|
xlogend);
|
2018-12-29 13:21:47 +01:00
|
|
|
exit(1);
|
2011-10-26 20:13:33 +02:00
|
|
|
}
|
2012-06-24 21:14:31 +02:00
|
|
|
xlogendptr = ((uint64) hi) << 32 | lo;
|
2011-10-26 20:13:33 +02:00
|
|
|
InterlockedIncrement(&has_xlogendptr);
|
|
|
|
|
|
|
|
/* First wait for the thread to exit */
|
2016-04-29 13:59:47 +02:00
|
|
|
if (WaitForSingleObjectEx((HANDLE) bgchild_handle, INFINITE, FALSE) !=
|
2012-07-31 16:11:11 +02:00
|
|
|
WAIT_OBJECT_0)
|
2011-10-26 20:13:33 +02:00
|
|
|
{
|
|
|
|
_dosmaperr(GetLastError());
|
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 wait for child thread: %m");
|
2018-12-29 13:21:47 +01:00
|
|
|
exit(1);
|
2011-10-26 20:13:33 +02:00
|
|
|
}
|
2016-04-29 13:59:47 +02:00
|
|
|
if (GetExitCodeThread((HANDLE) bgchild_handle, &status) == 0)
|
2011-10-26 20:13:33 +02:00
|
|
|
{
|
|
|
|
_dosmaperr(GetLastError());
|
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 get child thread exit status: %m");
|
2018-12-29 13:21:47 +01:00
|
|
|
exit(1);
|
2011-10-26 20:13:33 +02:00
|
|
|
}
|
|
|
|
if (status != 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("child thread exited with error %u",
|
|
|
|
(unsigned int) status);
|
2018-12-29 13:21:47 +01:00
|
|
|
exit(1);
|
2011-10-26 20:13:33 +02:00
|
|
|
}
|
|
|
|
/* Exited normally, we're happy */
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
2018-11-25 16:31:16 +01:00
|
|
|
/* Free the configuration file contents */
|
2013-01-05 16:54:06 +01:00
|
|
|
destroyPQExpBuffer(recoveryconfcontents);
|
|
|
|
|
2011-01-23 12:21:23 +01:00
|
|
|
/*
|
|
|
|
* End of copy data. Final result is already checked inside the loop.
|
|
|
|
*/
|
2012-01-20 13:57:02 +01:00
|
|
|
PQclear(res);
|
2011-01-23 12:21:23 +01:00
|
|
|
PQfinish(conn);
|
2018-12-29 13:21:47 +01:00
|
|
|
conn = NULL;
|
2011-01-23 12:21:23 +01:00
|
|
|
|
2016-09-29 18:00:00 +02:00
|
|
|
/*
|
2017-05-17 22:31:56 +02:00
|
|
|
* Make data persistent on disk once backup is completed. For tar format
|
2019-09-04 06:21:11 +02:00
|
|
|
* sync the parent directory and all its contents as each tar file was not
|
|
|
|
* synced after being completed. In plain format, all the data of the
|
|
|
|
* base directory is synced, taking into account all the tablespaces.
|
2017-05-17 22:31:56 +02:00
|
|
|
* Errors are not considered fatal.
|
2016-09-29 18:00:00 +02:00
|
|
|
*/
|
2016-09-29 18:00:00 +02:00
|
|
|
if (do_sync)
|
2016-09-29 18:00:00 +02:00
|
|
|
{
|
2018-07-29 00:53:11 +02:00
|
|
|
if (verbose)
|
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_info("syncing data to disk ...");
|
2016-09-29 18:00:00 +02:00
|
|
|
if (format == 't')
|
|
|
|
{
|
|
|
|
if (strcmp(basedir, "-") != 0)
|
2019-09-04 06:21:11 +02:00
|
|
|
(void) fsync_dir_recurse(basedir);
|
2016-09-29 18:00:00 +02:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
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
|
|
|
(void) fsync_pgdata(basedir, serverVersion);
|
2016-09-29 18:00:00 +02:00
|
|
|
}
|
2016-09-29 18:00:00 +02:00
|
|
|
}
|
|
|
|
|
2011-01-23 12:21:23 +01:00
|
|
|
if (verbose)
|
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_info("base backup completed");
|
2011-01-23 12:21:23 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
int
|
|
|
|
main(int argc, char **argv)
|
|
|
|
{
|
|
|
|
static struct option long_options[] = {
|
|
|
|
{"help", no_argument, NULL, '?'},
|
|
|
|
{"version", no_argument, NULL, 'V'},
|
|
|
|
{"pgdata", required_argument, NULL, 'D'},
|
|
|
|
{"format", required_argument, NULL, 'F'},
|
|
|
|
{"checkpoint", required_argument, NULL, 'c'},
|
2017-09-26 22:07:52 +02:00
|
|
|
{"create-slot", no_argument, NULL, 'C'},
|
2014-02-27 22:55:57 +01:00
|
|
|
{"max-rate", required_argument, NULL, 'r'},
|
2013-01-05 16:54:06 +01:00
|
|
|
{"write-recovery-conf", no_argument, NULL, 'R'},
|
2015-07-22 03:06:45 +02:00
|
|
|
{"slot", required_argument, NULL, 'S'},
|
2014-02-22 19:38:06 +01:00
|
|
|
{"tablespace-mapping", required_argument, NULL, 'T'},
|
2017-02-09 22:42:51 +01:00
|
|
|
{"wal-method", required_argument, NULL, 'X'},
|
2011-05-30 00:02:02 +02:00
|
|
|
{"gzip", no_argument, NULL, 'z'},
|
2011-01-23 12:21:23 +01:00
|
|
|
{"compress", required_argument, NULL, 'Z'},
|
|
|
|
{"label", required_argument, NULL, 'l'},
|
2016-10-19 18:00:00 +02:00
|
|
|
{"no-clean", no_argument, NULL, 'n'},
|
|
|
|
{"no-sync", no_argument, NULL, 'N'},
|
2013-02-25 13:48:27 +01:00
|
|
|
{"dbname", required_argument, NULL, 'd'},
|
2011-01-23 12:21:23 +01:00
|
|
|
{"host", required_argument, NULL, 'h'},
|
|
|
|
{"port", required_argument, NULL, 'p'},
|
|
|
|
{"username", required_argument, NULL, 'U'},
|
|
|
|
{"no-password", no_argument, NULL, 'w'},
|
|
|
|
{"password", no_argument, NULL, 'W'},
|
2012-07-31 16:11:11 +02:00
|
|
|
{"status-interval", required_argument, NULL, 's'},
|
2011-01-23 12:21:23 +01:00
|
|
|
{"verbose", no_argument, NULL, 'v'},
|
|
|
|
{"progress", no_argument, NULL, 'P'},
|
2017-02-09 22:42:51 +01:00
|
|
|
{"waldir", required_argument, NULL, 1},
|
2017-01-16 13:56:43 +01:00
|
|
|
{"no-slot", no_argument, NULL, 2},
|
2018-05-21 16:01:49 +02:00
|
|
|
{"no-verify-checksums", no_argument, NULL, 3},
|
2011-01-23 12:21:23 +01:00
|
|
|
{NULL, 0, NULL, 0}
|
|
|
|
};
|
|
|
|
int c;
|
|
|
|
|
|
|
|
int option_index;
|
|
|
|
|
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_logging_init(argv[0]);
|
2011-01-23 12:21:23 +01:00
|
|
|
progname = get_progname(argv[0]);
|
|
|
|
set_pglocale_pgservice(argv[0], PG_TEXTDOMAIN("pg_basebackup"));
|
|
|
|
|
|
|
|
if (argc > 1)
|
|
|
|
{
|
|
|
|
if (strcmp(argv[1], "--help") == 0 || strcmp(argv[1], "-?") == 0)
|
|
|
|
{
|
|
|
|
usage();
|
|
|
|
exit(0);
|
|
|
|
}
|
|
|
|
else if (strcmp(argv[1], "-V") == 0
|
|
|
|
|| strcmp(argv[1], "--version") == 0)
|
|
|
|
{
|
|
|
|
puts("pg_basebackup (PostgreSQL) " PG_VERSION);
|
|
|
|
exit(0);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-09-12 18:00:00 +02:00
|
|
|
atexit(cleanup_directories_atexit);
|
|
|
|
|
2018-04-03 13:47:16 +02:00
|
|
|
while ((c = getopt_long(argc, argv, "CD:F:r:RS:T:X:l:nNzZ:d:c:h:p:U:s:wWkvP",
|
2011-01-23 12:21:23 +01:00
|
|
|
long_options, &option_index)) != -1)
|
|
|
|
{
|
|
|
|
switch (c)
|
|
|
|
{
|
2017-09-26 22:07:52 +02:00
|
|
|
case 'C':
|
|
|
|
create_slot = true;
|
|
|
|
break;
|
2011-01-23 12:21:23 +01:00
|
|
|
case 'D':
|
2012-10-02 21:35:10 +02:00
|
|
|
basedir = pg_strdup(optarg);
|
2011-01-23 12:21:23 +01:00
|
|
|
break;
|
|
|
|
case 'F':
|
|
|
|
if (strcmp(optarg, "p") == 0 || strcmp(optarg, "plain") == 0)
|
|
|
|
format = 'p';
|
|
|
|
else if (strcmp(optarg, "t") == 0 || strcmp(optarg, "tar") == 0)
|
|
|
|
format = 't';
|
|
|
|
else
|
|
|
|
{
|
2019-07-03 00:18:43 +02:00
|
|
|
pg_log_error("invalid output format \"%s\", must be \"plain\" or \"tar\"",
|
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
|
|
|
optarg);
|
2011-01-23 12:21:23 +01:00
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
break;
|
2014-02-27 22:55:57 +01:00
|
|
|
case 'r':
|
|
|
|
maxrate = parse_max_rate(optarg);
|
|
|
|
break;
|
2013-01-05 16:54:06 +01:00
|
|
|
case 'R':
|
|
|
|
writerecoveryconf = true;
|
|
|
|
break;
|
2015-07-22 03:06:45 +02:00
|
|
|
case 'S':
|
2017-01-16 13:56:43 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* When specifying replication slot name, use a permanent
|
|
|
|
* slot.
|
|
|
|
*/
|
2015-07-22 03:06:45 +02:00
|
|
|
replication_slot = pg_strdup(optarg);
|
2017-01-16 13:56:43 +01:00
|
|
|
temp_replication_slot = false;
|
|
|
|
break;
|
|
|
|
case 2:
|
|
|
|
no_slot = true;
|
2015-07-22 03:06:45 +02:00
|
|
|
break;
|
2014-02-22 19:38:06 +01:00
|
|
|
case 'T':
|
|
|
|
tablespace_list_append(optarg);
|
|
|
|
break;
|
2012-06-10 13:43:51 +02:00
|
|
|
case 'X':
|
2017-01-04 10:40:38 +01:00
|
|
|
if (strcmp(optarg, "n") == 0 ||
|
|
|
|
strcmp(optarg, "none") == 0)
|
2012-06-10 13:43:51 +02:00
|
|
|
{
|
2017-01-09 16:03:47 +01:00
|
|
|
includewal = NO_WAL;
|
2012-06-10 13:43:51 +02:00
|
|
|
}
|
2017-01-04 10:40:38 +01:00
|
|
|
else if (strcmp(optarg, "f") == 0 ||
|
2017-05-17 22:31:56 +02:00
|
|
|
strcmp(optarg, "fetch") == 0)
|
2017-01-04 10:40:38 +01:00
|
|
|
{
|
2017-01-09 16:03:47 +01:00
|
|
|
includewal = FETCH_WAL;
|
2017-01-04 10:40:38 +01:00
|
|
|
}
|
2011-10-26 20:13:33 +02:00
|
|
|
else if (strcmp(optarg, "s") == 0 ||
|
|
|
|
strcmp(optarg, "stream") == 0)
|
2017-01-04 10:40:38 +01:00
|
|
|
{
|
2017-01-09 16:03:47 +01:00
|
|
|
includewal = STREAM_WAL;
|
2017-01-04 10:40:38 +01:00
|
|
|
}
|
2011-10-26 20:13:33 +02:00
|
|
|
else
|
|
|
|
{
|
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("invalid wal-method option \"%s\", must be \"fetch\", \"stream\", or \"none\"",
|
|
|
|
optarg);
|
2011-10-26 20:13:33 +02:00
|
|
|
exit(1);
|
|
|
|
}
|
2011-01-30 21:30:09 +01:00
|
|
|
break;
|
2013-11-27 06:00:16 +01:00
|
|
|
case 1:
|
|
|
|
xlog_dir = pg_strdup(optarg);
|
|
|
|
break;
|
2011-01-23 12:21:23 +01:00
|
|
|
case 'l':
|
2012-10-02 21:35:10 +02:00
|
|
|
label = pg_strdup(optarg);
|
2011-01-23 12:21:23 +01:00
|
|
|
break;
|
2016-09-12 18:00:00 +02:00
|
|
|
case 'n':
|
|
|
|
noclean = true;
|
|
|
|
break;
|
2016-09-29 18:00:00 +02:00
|
|
|
case 'N':
|
|
|
|
do_sync = false;
|
|
|
|
break;
|
2011-05-30 00:02:02 +02:00
|
|
|
case 'z':
|
|
|
|
#ifdef HAVE_LIBZ
|
|
|
|
compresslevel = Z_DEFAULT_COMPRESSION;
|
|
|
|
#else
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
compresslevel = 1; /* will be rejected below */
|
2011-05-30 00:02:02 +02:00
|
|
|
#endif
|
|
|
|
break;
|
2011-01-23 12:21:23 +01:00
|
|
|
case 'Z':
|
|
|
|
compresslevel = atoi(optarg);
|
2016-08-01 10:36:14 +02:00
|
|
|
if (compresslevel < 0 || compresslevel > 9)
|
2011-01-23 12:21:23 +01:00
|
|
|
{
|
2019-07-03 00:18:43 +02:00
|
|
|
pg_log_error("invalid compression level \"%s\"", optarg);
|
2011-01-23 12:21:23 +01:00
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case 'c':
|
2011-01-23 17:35:02 +01:00
|
|
|
if (pg_strcasecmp(optarg, "fast") == 0)
|
2011-01-23 12:21:23 +01:00
|
|
|
fastcheckpoint = true;
|
2011-01-23 17:35:02 +01:00
|
|
|
else if (pg_strcasecmp(optarg, "spread") == 0)
|
2011-01-23 12:21:23 +01:00
|
|
|
fastcheckpoint = false;
|
|
|
|
else
|
|
|
|
{
|
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("invalid checkpoint argument \"%s\", must be \"fast\" or \"spread\"",
|
|
|
|
optarg);
|
2011-01-23 12:21:23 +01:00
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
break;
|
2013-02-25 13:48:27 +01:00
|
|
|
case 'd':
|
|
|
|
connection_string = pg_strdup(optarg);
|
|
|
|
break;
|
2011-01-23 12:21:23 +01:00
|
|
|
case 'h':
|
2012-10-02 21:35:10 +02:00
|
|
|
dbhost = pg_strdup(optarg);
|
2011-01-23 12:21:23 +01:00
|
|
|
break;
|
|
|
|
case 'p':
|
2012-10-02 21:35:10 +02:00
|
|
|
dbport = pg_strdup(optarg);
|
2011-01-23 12:21:23 +01:00
|
|
|
break;
|
|
|
|
case 'U':
|
2012-10-02 21:35:10 +02:00
|
|
|
dbuser = pg_strdup(optarg);
|
2011-01-23 12:21:23 +01:00
|
|
|
break;
|
|
|
|
case 'w':
|
|
|
|
dbgetpassword = -1;
|
|
|
|
break;
|
|
|
|
case 'W':
|
|
|
|
dbgetpassword = 1;
|
|
|
|
break;
|
2011-10-26 20:13:33 +02:00
|
|
|
case 's':
|
2012-06-10 12:12:36 +02:00
|
|
|
standby_message_timeout = atoi(optarg) * 1000;
|
2011-10-26 20:13:33 +02:00
|
|
|
if (standby_message_timeout < 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("invalid status interval \"%s\"", optarg);
|
2011-10-26 20:13:33 +02:00
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
break;
|
2011-01-23 12:21:23 +01:00
|
|
|
case 'v':
|
|
|
|
verbose++;
|
|
|
|
break;
|
|
|
|
case 'P':
|
|
|
|
showprogress = true;
|
|
|
|
break;
|
2018-05-21 16:01:49 +02:00
|
|
|
case 3:
|
2018-04-03 13:47:16 +02:00
|
|
|
verify_checksums = false;
|
|
|
|
break;
|
2011-01-23 12:21:23 +01:00
|
|
|
default:
|
|
|
|
|
|
|
|
/*
|
|
|
|
* getopt_long already emitted a complaint
|
|
|
|
*/
|
|
|
|
fprintf(stderr, _("Try \"%s --help\" for more information.\n"),
|
|
|
|
progname);
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Any non-option arguments?
|
|
|
|
*/
|
|
|
|
if (optind < argc)
|
|
|
|
{
|
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("too many command-line arguments (first is \"%s\")",
|
|
|
|
argv[optind]);
|
2011-01-23 12:21:23 +01:00
|
|
|
fprintf(stderr, _("Try \"%s --help\" for more information.\n"),
|
|
|
|
progname);
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Required arguments
|
|
|
|
*/
|
|
|
|
if (basedir == 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("no target directory specified");
|
2011-01-23 12:21:23 +01:00
|
|
|
fprintf(stderr, _("Try \"%s --help\" for more information.\n"),
|
|
|
|
progname);
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Mutually exclusive arguments
|
|
|
|
*/
|
2011-06-15 19:15:05 +02:00
|
|
|
if (format == 'p' && compresslevel != 0)
|
2011-01-23 12:21:23 +01:00
|
|
|
{
|
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("only tar mode backups can be compressed");
|
2011-01-23 12:21:23 +01:00
|
|
|
fprintf(stderr, _("Try \"%s --help\" for more information.\n"),
|
|
|
|
progname);
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
2017-01-09 16:03:47 +01:00
|
|
|
if (format == 't' && includewal == STREAM_WAL && strcmp(basedir, "-") == 0)
|
2016-12-21 12:27:37 +01:00
|
|
|
{
|
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("cannot stream write-ahead logs in tar mode to stdout");
|
2016-12-21 12:27:37 +01:00
|
|
|
fprintf(stderr, _("Try \"%s --help\" for more information.\n"),
|
|
|
|
progname);
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
2017-01-16 18:20:57 +01:00
|
|
|
if (replication_slot && includewal != STREAM_WAL)
|
2015-07-22 03:06:45 +02:00
|
|
|
{
|
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("replication slots can only be used with WAL streaming");
|
2015-07-22 03:06:45 +02:00
|
|
|
fprintf(stderr, _("Try \"%s --help\" for more information.\n"),
|
|
|
|
progname);
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
2017-01-16 13:56:43 +01:00
|
|
|
if (no_slot)
|
|
|
|
{
|
|
|
|
if (replication_slot)
|
|
|
|
{
|
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("--no-slot cannot be used with slot name");
|
2017-01-16 13:56:43 +01:00
|
|
|
fprintf(stderr, _("Try \"%s --help\" for more information.\n"),
|
|
|
|
progname);
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
temp_replication_slot = false;
|
|
|
|
}
|
|
|
|
|
2017-09-26 22:07:52 +02:00
|
|
|
if (create_slot)
|
|
|
|
{
|
|
|
|
if (!replication_slot)
|
|
|
|
{
|
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("%s needs a slot to be specified using --slot",
|
|
|
|
"--create-slot");
|
2017-09-26 22:07:52 +02:00
|
|
|
fprintf(stderr, _("Try \"%s --help\" for more information.\n"),
|
|
|
|
progname);
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (no_slot)
|
|
|
|
{
|
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("--create-slot and --no-slot are incompatible options");
|
2017-09-26 22:07:52 +02:00
|
|
|
fprintf(stderr, _("Try \"%s --help\" for more information.\n"),
|
|
|
|
progname);
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-08-31 04:28:36 +02:00
|
|
|
if (xlog_dir)
|
2013-11-27 06:00:16 +01:00
|
|
|
{
|
|
|
|
if (format != 'p')
|
|
|
|
{
|
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("WAL directory location can only be specified in plain mode");
|
2013-11-27 06:00:16 +01:00
|
|
|
fprintf(stderr, _("Try \"%s --help\" for more information.\n"),
|
|
|
|
progname);
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* clean up xlog directory name, check it's absolute */
|
|
|
|
canonicalize_path(xlog_dir);
|
|
|
|
if (!is_absolute_path(xlog_dir))
|
|
|
|
{
|
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("WAL directory location must be an absolute path");
|
2013-11-27 06:00:16 +01:00
|
|
|
fprintf(stderr, _("Try \"%s --help\" for more information.\n"),
|
|
|
|
progname);
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-01-23 12:21:23 +01:00
|
|
|
#ifndef HAVE_LIBZ
|
2011-06-15 19:15:05 +02:00
|
|
|
if (compresslevel != 0)
|
2011-01-23 12:21:23 +01:00
|
|
|
{
|
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("this build does not support compression");
|
2011-01-23 12:21:23 +01:00
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2016-10-20 17:24:37 +02:00
|
|
|
/* connection in replication mode to server */
|
|
|
|
conn = GetConnection();
|
|
|
|
if (!conn)
|
|
|
|
{
|
|
|
|
/* Error message already written in GetConnection() */
|
|
|
|
exit(1);
|
|
|
|
}
|
2018-12-29 13:21:47 +01:00
|
|
|
atexit(disconnect_atexit);
|
2016-10-20 17:24:37 +02:00
|
|
|
|
2018-04-07 23:45:39 +02:00
|
|
|
/*
|
|
|
|
* Set umask so that directories/files are created with the same
|
|
|
|
* permissions as directories/files in the source data directory.
|
|
|
|
*
|
|
|
|
* pg_mode_mask is set to owner-only by default and then updated in
|
|
|
|
* GetConnection() where we get the mode from the server-side with
|
|
|
|
* RetrieveDataDirCreatePerm() and then call SetDataDirectoryCreatePerm().
|
|
|
|
*/
|
|
|
|
umask(pg_mode_mask);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Verify that the target directory exists, or create it. For plaintext
|
|
|
|
* backups, always require the directory. For tar backups, require it
|
|
|
|
* unless we are writing to stdout.
|
|
|
|
*/
|
|
|
|
if (format == 'p' || strcmp(basedir, "-") != 0)
|
|
|
|
verify_dir_is_empty_or_create(basedir, &made_new_pgdata, &found_existing_pgdata);
|
|
|
|
|
Make WAL segment size configurable at initdb time.
For performance reasons a larger segment size than the default 16MB
can be useful. A larger segment size has two main benefits: Firstly,
in setups using archiving, it makes it easier to write scripts that
can keep up with higher amounts of WAL, secondly, the WAL has to be
written and synced to disk less frequently.
But at the same time large segment size are disadvantageous for
smaller databases. So far the segment size had to be configured at
compile time, often making it unrealistic to choose one fitting to a
particularly load. Therefore change it to a initdb time setting.
This includes a breaking changes to the xlogreader.h API, which now
requires the current segment size to be configured. For that and
similar reasons a number of binaries had to be taught how to recognize
the current segment size.
Author: Beena Emerson, editorialized by Andres Freund
Reviewed-By: Andres Freund, David Steele, Kuntal Ghosh, Michael
Paquier, Peter Eisentraut, Robert Hass, Tushar Ahuja
Discussion: https://postgr.es/m/CAOG9ApEAcQ--1ieKbhFzXSQPw_YLmepaa4hNdnY5+ZULpt81Mw@mail.gmail.com
2017-09-20 07:03:48 +02:00
|
|
|
/* determine remote server's xlog segment size */
|
|
|
|
if (!RetrieveWalSegSize(conn))
|
2018-12-29 13:21:47 +01:00
|
|
|
exit(1);
|
Make WAL segment size configurable at initdb time.
For performance reasons a larger segment size than the default 16MB
can be useful. A larger segment size has two main benefits: Firstly,
in setups using archiving, it makes it easier to write scripts that
can keep up with higher amounts of WAL, secondly, the WAL has to be
written and synced to disk less frequently.
But at the same time large segment size are disadvantageous for
smaller databases. So far the segment size had to be configured at
compile time, often making it unrealistic to choose one fitting to a
particularly load. Therefore change it to a initdb time setting.
This includes a breaking changes to the xlogreader.h API, which now
requires the current segment size to be configured. For that and
similar reasons a number of binaries had to be taught how to recognize
the current segment size.
Author: Beena Emerson, editorialized by Andres Freund
Reviewed-By: Andres Freund, David Steele, Kuntal Ghosh, Michael
Paquier, Peter Eisentraut, Robert Hass, Tushar Ahuja
Discussion: https://postgr.es/m/CAOG9ApEAcQ--1ieKbhFzXSQPw_YLmepaa4hNdnY5+ZULpt81Mw@mail.gmail.com
2017-09-20 07:03:48 +02:00
|
|
|
|
2017-05-12 17:49:56 +02:00
|
|
|
/* Create pg_wal symlink, if required */
|
2017-08-31 04:28:36 +02:00
|
|
|
if (xlog_dir)
|
2013-11-27 06:00:16 +01:00
|
|
|
{
|
|
|
|
char *linkloc;
|
|
|
|
|
2016-09-12 18:00:00 +02:00
|
|
|
verify_dir_is_empty_or_create(xlog_dir, &made_new_xlogdir, &found_existing_xlogdir);
|
2013-11-27 06:00:16 +01:00
|
|
|
|
2016-10-20 17:24:37 +02:00
|
|
|
/*
|
2017-05-17 22:31:56 +02:00
|
|
|
* Form name of the place where the symlink must go. pg_xlog has been
|
|
|
|
* renamed to pg_wal in post-10 clusters.
|
2016-10-20 17:24:37 +02:00
|
|
|
*/
|
|
|
|
linkloc = psprintf("%s/%s", basedir,
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
PQserverVersion(conn) < MINIMUM_VERSION_FOR_PG_WAL ?
|
2017-05-17 22:31:56 +02:00
|
|
|
"pg_xlog" : "pg_wal");
|
2013-11-27 06:00:16 +01:00
|
|
|
|
|
|
|
#ifdef HAVE_SYMLINK
|
|
|
|
if (symlink(xlog_dir, linkloc) != 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 create symbolic link \"%s\": %m", linkloc);
|
2018-12-29 13:21:47 +01:00
|
|
|
exit(1);
|
2013-11-27 06:00:16 +01:00
|
|
|
}
|
|
|
|
#else
|
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("symlinks are not supported on this platform");
|
2018-12-29 13:21:47 +01:00
|
|
|
exit(1);
|
2013-11-27 06:00:16 +01:00
|
|
|
#endif
|
|
|
|
free(linkloc);
|
|
|
|
}
|
|
|
|
|
2011-01-23 12:21:23 +01:00
|
|
|
BaseBackup();
|
|
|
|
|
2016-09-12 18:00:00 +02:00
|
|
|
success = true;
|
2011-01-23 12:21:23 +01:00
|
|
|
return 0;
|
|
|
|
}
|