2001-03-13 02:17:40 +01:00
|
|
|
/*
|
|
|
|
|
* pg_controldata
|
2001-02-23 21:38:35 +01:00
|
|
|
*
|
|
|
|
|
* reads the data from $PGDATA/global/pg_control
|
|
|
|
|
*
|
|
|
|
|
* copyright (c) Oliver Elphick <olly@lfix.co.uk>, 2001;
|
2019-07-29 05:28:30 +02:00
|
|
|
* license: BSD
|
2001-02-23 21:38:35 +01:00
|
|
|
*
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/bin/pg_controldata/pg_controldata.c
|
2001-03-13 02:17:40 +01:00
|
|
|
*/
|
2010-04-28 19:35:35 +02:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* We have to use postgres.h not postgres_fe.h here, because there's so much
|
|
|
|
|
* backend-only stuff in the XLOG include files we need. But we need a
|
2014-05-06 18:12:18 +02:00
|
|
|
* frontend-ish environment otherwise. Hence this ugly hack.
|
2010-04-28 19:35:35 +02:00
|
|
|
*/
|
|
|
|
|
#define FRONTEND 1
|
|
|
|
|
|
Introduce wal_level GUC to explicitly control if information needed for
archival or hot standby should be WAL-logged, instead of deducing that from
other options like archive_mode. This replaces recovery_connections GUC in
the primary, where it now has no effect, but it's still used in the standby
to enable/disable hot standby.
Remove the WAL-logging of "unlogged operations", like creating an index
without WAL-logging and fsyncing it at the end. Instead, we keep a copy of
the wal_mode setting and the settings that affect how much shared memory a
hot standby server needs to track master transactions (max_connections,
max_prepared_xacts, max_locks_per_xact) in pg_control. Whenever the settings
change, at server restart, write a WAL record noting the new settings and
update pg_control. This allows us to notice the change in those settings in
the standby at the right moment, they used to be included in checkpoint
records, but that meant that a changed value was not reflected in the
standby until the first checkpoint after the change.
Bump PG_CONTROL_VERSION and XLOG_PAGE_MAGIC. Whack XLOG_PAGE_MAGIC back to
the sequence it used to follow, before hot standby and subsequent patches
changed it to 0x9003.
2010-04-28 18:10:43 +02:00
|
|
|
#include "postgres.h"
|
2001-02-23 21:38:35 +01:00
|
|
|
|
|
|
|
|
#include <time.h>
|
|
|
|
|
|
2019-03-27 22:34:43 +01:00
|
|
|
#include "access/transam.h"
|
Introduce wal_level GUC to explicitly control if information needed for
archival or hot standby should be WAL-logged, instead of deducing that from
other options like archive_mode. This replaces recovery_connections GUC in
the primary, where it now has no effect, but it's still used in the standby
to enable/disable hot standby.
Remove the WAL-logging of "unlogged operations", like creating an index
without WAL-logging and fsyncing it at the end. Instead, we keep a copy of
the wal_mode setting and the settings that affect how much shared memory a
hot standby server needs to track master transactions (max_connections,
max_prepared_xacts, max_locks_per_xact) in pg_control. Whenever the settings
change, at server restart, write a WAL record noting the new settings and
update pg_control. This allows us to notice the change in those settings in
the standby at the right moment, they used to be included in checkpoint
records, but that meant that a changed value was not reflected in the
standby until the first checkpoint after the change.
Bump PG_CONTROL_VERSION and XLOG_PAGE_MAGIC. Whack XLOG_PAGE_MAGIC back to
the sequence it used to follow, before hot standby and subsequent patches
changed it to 0x9003.
2010-04-28 18:10:43 +02:00
|
|
|
#include "access/xlog.h"
|
2012-07-14 13:17:43 +02:00
|
|
|
#include "access/xlog_internal.h"
|
2001-03-13 02:17:40 +01:00
|
|
|
#include "catalog/pg_control.h"
|
2016-03-05 20:10:19 +01:00
|
|
|
#include "common/controldata_utils.h"
|
2019-05-14 20:19:49 +02:00
|
|
|
#include "common/logging.h"
|
2018-03-25 06:46:43 +02:00
|
|
|
#include "getopt_long.h"
|
2019-10-23 06:08:53 +02:00
|
|
|
#include "pg_getopt.h"
|
2002-08-22 00:24:34 +02:00
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
usage(const char *progname)
|
|
|
|
|
{
|
2003-07-23 10:47:41 +02:00
|
|
|
printf(_("%s displays control information of a PostgreSQL database cluster.\n\n"), progname);
|
2012-06-18 01:44:00 +02:00
|
|
|
printf(_("Usage:\n"));
|
2015-09-16 06:37:39 +02:00
|
|
|
printf(_(" %s [OPTION] [DATADIR]\n"), progname);
|
2012-06-18 01:44:00 +02:00
|
|
|
printf(_("\nOptions:\n"));
|
2018-05-18 05:05:27 +02:00
|
|
|
printf(_(" [-D, --pgdata=]DATADIR data directory\n"));
|
|
|
|
|
printf(_(" -V, --version output version information, then exit\n"));
|
|
|
|
|
printf(_(" -?, --help show this help, then exit\n"));
|
2004-09-23 02:47:44 +02:00
|
|
|
printf(_("\nIf no data directory (DATADIR) is specified, "
|
|
|
|
|
"the environment variable PGDATA\nis used.\n\n"));
|
2020-02-28 08:54:49 +01:00
|
|
|
printf(_("Report bugs to <%s>.\n"), PACKAGE_BUGREPORT);
|
2020-02-28 08:54:49 +01:00
|
|
|
printf(_("%s home page: <%s>\n"), PACKAGE_NAME, PACKAGE_URL);
|
2002-08-22 00:24:34 +02:00
|
|
|
}
|
|
|
|
|
|
2001-02-23 21:38:35 +01:00
|
|
|
|
2001-03-13 02:17:40 +01:00
|
|
|
static const char *
|
|
|
|
|
dbState(DBState state)
|
2001-02-23 21:38:35 +01:00
|
|
|
{
|
2001-03-13 02:17:40 +01:00
|
|
|
switch (state)
|
|
|
|
|
{
|
2001-10-25 07:50:21 +02:00
|
|
|
case DB_STARTUP:
|
2002-09-03 00:18:26 +02:00
|
|
|
return _("starting up");
|
2001-03-13 02:17:40 +01:00
|
|
|
case DB_SHUTDOWNED:
|
2002-09-03 00:18:26 +02:00
|
|
|
return _("shut down");
|
2010-06-03 05:20:00 +02:00
|
|
|
case DB_SHUTDOWNED_IN_RECOVERY:
|
|
|
|
|
return _("shut down in recovery");
|
2001-03-13 02:17:40 +01:00
|
|
|
case DB_SHUTDOWNING:
|
2002-09-03 00:18:26 +02:00
|
|
|
return _("shutting down");
|
2006-08-07 18:57:57 +02:00
|
|
|
case DB_IN_CRASH_RECOVERY:
|
|
|
|
|
return _("in crash recovery");
|
|
|
|
|
case DB_IN_ARCHIVE_RECOVERY:
|
|
|
|
|
return _("in archive recovery");
|
2001-03-13 02:17:40 +01:00
|
|
|
case DB_IN_PRODUCTION:
|
2002-09-03 00:18:26 +02:00
|
|
|
return _("in production");
|
2001-03-13 02:17:40 +01:00
|
|
|
}
|
2002-08-22 00:24:34 +02:00
|
|
|
return _("unrecognized status code");
|
2001-03-13 02:17:40 +01:00
|
|
|
}
|
2001-02-23 21:38:35 +01:00
|
|
|
|
Introduce wal_level GUC to explicitly control if information needed for
archival or hot standby should be WAL-logged, instead of deducing that from
other options like archive_mode. This replaces recovery_connections GUC in
the primary, where it now has no effect, but it's still used in the standby
to enable/disable hot standby.
Remove the WAL-logging of "unlogged operations", like creating an index
without WAL-logging and fsyncing it at the end. Instead, we keep a copy of
the wal_mode setting and the settings that affect how much shared memory a
hot standby server needs to track master transactions (max_connections,
max_prepared_xacts, max_locks_per_xact) in pg_control. Whenever the settings
change, at server restart, write a WAL record noting the new settings and
update pg_control. This allows us to notice the change in those settings in
the standby at the right moment, they used to be included in checkpoint
records, but that meant that a changed value was not reflected in the
standby until the first checkpoint after the change.
Bump PG_CONTROL_VERSION and XLOG_PAGE_MAGIC. Whack XLOG_PAGE_MAGIC back to
the sequence it used to follow, before hot standby and subsequent patches
changed it to 0x9003.
2010-04-28 18:10:43 +02:00
|
|
|
static const char *
|
|
|
|
|
wal_level_str(WalLevel wal_level)
|
|
|
|
|
{
|
|
|
|
|
switch (wal_level)
|
|
|
|
|
{
|
|
|
|
|
case WAL_LEVEL_MINIMAL:
|
|
|
|
|
return "minimal";
|
2016-03-01 02:01:54 +01:00
|
|
|
case WAL_LEVEL_REPLICA:
|
|
|
|
|
return "replica";
|
Add new wal_level, logical, sufficient for logical decoding.
When wal_level=logical, we'll log columns from the old tuple as
configured by the REPLICA IDENTITY facility added in commit
07cacba983ef79be4a84fcd0e0ca3b5fcb85dd65. This makes it possible
a properly-configured logical replication solution to correctly
follow table updates even if they change the chosen key columns,
or, with REPLICA IDENTITY FULL, even if the table has no key at
all. Note that updates which do not modify the replica identity
column won't log anything extra, making the choice of a good key
(i.e. one that will rarely be changed) important to performance
when wal_level=logical is configured.
Each insert, update, or delete to a catalog table will also log
the CMIN and/or CMAX values of stamped by the current transaction.
This is necessary because logical decoding will require access to
historical snapshots of the catalog in order to decode some data
types, and the CMIN/CMAX values that we may need in order to judge
row visibility may have been overwritten by the time we need them.
Andres Freund, reviewed in various versions by myself, Heikki
Linnakangas, KONDO Mitsumasa, and many others.
2013-12-11 00:33:45 +01:00
|
|
|
case WAL_LEVEL_LOGICAL:
|
|
|
|
|
return "logical";
|
Introduce wal_level GUC to explicitly control if information needed for
archival or hot standby should be WAL-logged, instead of deducing that from
other options like archive_mode. This replaces recovery_connections GUC in
the primary, where it now has no effect, but it's still used in the standby
to enable/disable hot standby.
Remove the WAL-logging of "unlogged operations", like creating an index
without WAL-logging and fsyncing it at the end. Instead, we keep a copy of
the wal_mode setting and the settings that affect how much shared memory a
hot standby server needs to track master transactions (max_connections,
max_prepared_xacts, max_locks_per_xact) in pg_control. Whenever the settings
change, at server restart, write a WAL record noting the new settings and
update pg_control. This allows us to notice the change in those settings in
the standby at the right moment, they used to be included in checkpoint
records, but that meant that a changed value was not reflected in the
standby until the first checkpoint after the change.
Bump PG_CONTROL_VERSION and XLOG_PAGE_MAGIC. Whack XLOG_PAGE_MAGIC back to
the sequence it used to follow, before hot standby and subsequent patches
changed it to 0x9003.
2010-04-28 18:10:43 +02:00
|
|
|
}
|
|
|
|
|
return _("unrecognized wal_level");
|
|
|
|
|
}
|
|
|
|
|
|
2001-02-23 21:38:35 +01:00
|
|
|
|
2001-03-13 02:17:40 +01:00
|
|
|
int
|
2001-09-06 12:49:30 +02:00
|
|
|
main(int argc, char *argv[])
|
2001-02-23 21:38:35 +01:00
|
|
|
{
|
2018-03-25 03:14:20 +02:00
|
|
|
static struct option long_options[] = {
|
|
|
|
|
{"pgdata", required_argument, NULL, 'D'},
|
|
|
|
|
{NULL, 0, NULL, 0}
|
|
|
|
|
};
|
|
|
|
|
|
2016-03-05 20:10:19 +01:00
|
|
|
ControlFileData *ControlFile;
|
2016-09-28 18:00:00 +02:00
|
|
|
bool crc_ok;
|
2014-10-24 17:55:33 +02:00
|
|
|
char *DataDir = NULL;
|
2008-02-17 03:09:32 +01:00
|
|
|
time_t time_tmp;
|
2004-03-22 16:34:22 +01:00
|
|
|
char pgctime_str[128];
|
|
|
|
|
char ckpttime_str[128];
|
Support SCRAM-SHA-256 authentication (RFC 5802 and 7677).
This introduces a new generic SASL authentication method, similar to the
GSS and SSPI methods. The server first tells the client which SASL
authentication mechanism to use, and then the mechanism-specific SASL
messages are exchanged in AuthenticationSASLcontinue and PasswordMessage
messages. Only SCRAM-SHA-256 is supported at the moment, but this allows
adding more SASL mechanisms in the future, without changing the overall
protocol.
Support for channel binding, aka SCRAM-SHA-256-PLUS is left for later.
The SASLPrep algorithm, for pre-processing the password, is not yet
implemented. That could cause trouble, if you use a password with
non-ASCII characters, and a client library that does implement SASLprep.
That will hopefully be added later.
Authorization identities, as specified in the SCRAM-SHA-256 specification,
are ignored. SET SESSION AUTHORIZATION provides more or less the same
functionality, anyway.
If a user doesn't exist, perform a "mock" authentication, by constructing
an authentic-looking challenge on the fly. The challenge is derived from
a new system-wide random value, "mock authentication nonce", which is
created at initdb, and stored in the control file. We go through these
motions, in order to not give away the information on whether the user
exists, to unauthenticated users.
Bumps PG_CONTROL_VERSION, because of the new field in control file.
Patch by Michael Paquier and Heikki Linnakangas, reviewed at different
stages by Robert Haas, Stephen Frost, David Steele, Aleksander Alekseev,
and many others.
Discussion: https://www.postgresql.org/message-id/CAB7nPqRbR3GmFYdedCAhzukfKrgBLTLtMvENOmPrVWREsZkF8g%40mail.gmail.com
Discussion: https://www.postgresql.org/message-id/CAB7nPqSMXU35g%3DW9X74HVeQp0uvgJxvYOuA4A-A3M%2B0wfEBv-w%40mail.gmail.com
Discussion: https://www.postgresql.org/message-id/55192AFE.6080106@iki.fi
2017-03-07 13:25:40 +01:00
|
|
|
char mock_auth_nonce_str[MOCK_AUTH_NONCE_LEN * 2 + 1];
|
2007-03-18 17:50:44 +01:00
|
|
|
const char *strftime_fmt = "%c";
|
2004-05-12 15:38:49 +02:00
|
|
|
const char *progname;
|
2012-07-14 13:17:43 +02:00
|
|
|
char xlogfilename[MAXFNAMELEN];
|
2014-10-24 17:55:33 +02:00
|
|
|
int c;
|
Support SCRAM-SHA-256 authentication (RFC 5802 and 7677).
This introduces a new generic SASL authentication method, similar to the
GSS and SSPI methods. The server first tells the client which SASL
authentication mechanism to use, and then the mechanism-specific SASL
messages are exchanged in AuthenticationSASLcontinue and PasswordMessage
messages. Only SCRAM-SHA-256 is supported at the moment, but this allows
adding more SASL mechanisms in the future, without changing the overall
protocol.
Support for channel binding, aka SCRAM-SHA-256-PLUS is left for later.
The SASLPrep algorithm, for pre-processing the password, is not yet
implemented. That could cause trouble, if you use a password with
non-ASCII characters, and a client library that does implement SASLprep.
That will hopefully be added later.
Authorization identities, as specified in the SCRAM-SHA-256 specification,
are ignored. SET SESSION AUTHORIZATION provides more or less the same
functionality, anyway.
If a user doesn't exist, perform a "mock" authentication, by constructing
an authentic-looking challenge on the fly. The challenge is derived from
a new system-wide random value, "mock authentication nonce", which is
created at initdb, and stored in the control file. We go through these
motions, in order to not give away the information on whether the user
exists, to unauthenticated users.
Bumps PG_CONTROL_VERSION, because of the new field in control file.
Patch by Michael Paquier and Heikki Linnakangas, reviewed at different
stages by Robert Haas, Stephen Frost, David Steele, Aleksander Alekseev,
and many others.
Discussion: https://www.postgresql.org/message-id/CAB7nPqRbR3GmFYdedCAhzukfKrgBLTLtMvENOmPrVWREsZkF8g%40mail.gmail.com
Discussion: https://www.postgresql.org/message-id/CAB7nPqSMXU35g%3DW9X74HVeQp0uvgJxvYOuA4A-A3M%2B0wfEBv-w%40mail.gmail.com
Discussion: https://www.postgresql.org/message-id/55192AFE.6080106@iki.fi
2017-03-07 13:25:40 +01:00
|
|
|
int i;
|
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
|
|
|
int WalSegSz;
|
2002-08-22 00:24:34 +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_logging_init(argv[0]);
|
2008-12-11 08:34:09 +01:00
|
|
|
set_pglocale_pgservice(argv[0], PG_TEXTDOMAIN("pg_controldata"));
|
2003-04-04 22:42:13 +02:00
|
|
|
progname = get_progname(argv[0]);
|
2002-08-22 00:24:34 +02:00
|
|
|
|
|
|
|
|
if (argc > 1)
|
|
|
|
|
{
|
|
|
|
|
if (strcmp(argv[1], "--help") == 0 || strcmp(argv[1], "-?") == 0)
|
|
|
|
|
{
|
|
|
|
|
usage(progname);
|
|
|
|
|
exit(0);
|
|
|
|
|
}
|
|
|
|
|
if (strcmp(argv[1], "--version") == 0 || strcmp(argv[1], "-V") == 0)
|
|
|
|
|
{
|
|
|
|
|
puts("pg_controldata (PostgreSQL) " PG_VERSION);
|
|
|
|
|
exit(0);
|
|
|
|
|
}
|
|
|
|
|
}
|
2001-02-23 21:38:35 +01:00
|
|
|
|
2018-03-25 03:14:20 +02:00
|
|
|
while ((c = getopt_long(argc, argv, "D:", long_options, NULL)) != -1)
|
2014-10-24 17:55:33 +02:00
|
|
|
{
|
|
|
|
|
switch (c)
|
|
|
|
|
{
|
|
|
|
|
case 'D':
|
|
|
|
|
DataDir = optarg;
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
default:
|
|
|
|
|
fprintf(stderr, _("Try \"%s --help\" for more information.\n"), progname);
|
|
|
|
|
exit(1);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (DataDir == NULL)
|
|
|
|
|
{
|
|
|
|
|
if (optind < argc)
|
|
|
|
|
DataDir = argv[optind++];
|
|
|
|
|
else
|
|
|
|
|
DataDir = getenv("PGDATA");
|
|
|
|
|
}
|
|
|
|
|
|
2014-10-24 17:59:08 +02:00
|
|
|
/* Complain if any arguments remain */
|
|
|
|
|
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]);
|
2014-10-24 17:59:08 +02:00
|
|
|
fprintf(stderr, _("Try \"%s --help\" for more information.\n"),
|
|
|
|
|
progname);
|
|
|
|
|
exit(1);
|
|
|
|
|
}
|
|
|
|
|
|
2001-03-22 05:01:46 +01:00
|
|
|
if (DataDir == 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 data directory specified");
|
2003-07-23 10:47:41 +02:00
|
|
|
fprintf(stderr, _("Try \"%s --help\" for more information.\n"), progname);
|
2001-02-23 21:38:35 +01:00
|
|
|
exit(1);
|
|
|
|
|
}
|
|
|
|
|
|
2016-03-05 20:10:19 +01:00
|
|
|
/* get a copy of the control file */
|
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
|
|
|
ControlFile = get_controlfile(DataDir, &crc_ok);
|
2016-09-28 18:00:00 +02:00
|
|
|
if (!crc_ok)
|
2016-07-26 17:23:43 +02:00
|
|
|
printf(_("WARNING: Calculated CRC checksum does not match value stored in file.\n"
|
|
|
|
|
"Either the file is corrupt, or it has a different layout than this program\n"
|
|
|
|
|
"is expecting. The results below are untrustworthy.\n\n"));
|
2001-03-13 02:17:40 +01:00
|
|
|
|
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
|
|
|
/* set wal segment size */
|
|
|
|
|
WalSegSz = ControlFile->xlog_seg_size;
|
|
|
|
|
|
|
|
|
|
if (!IsValidWalSegSize(WalSegSz))
|
2018-05-18 05:05:27 +02:00
|
|
|
{
|
|
|
|
|
printf(_("WARNING: invalid WAL segment size\n"));
|
|
|
|
|
printf(ngettext("The WAL segment size stored in the file, %d byte, is not a power of two\n"
|
|
|
|
|
"between 1 MB and 1 GB. The file is corrupt and the results below are\n"
|
|
|
|
|
"untrustworthy.\n\n",
|
|
|
|
|
"The WAL segment size stored in the file, %d bytes, is not a power of two\n"
|
|
|
|
|
"between 1 MB and 1 GB. The file is corrupt and the results below are\n"
|
|
|
|
|
"untrustworthy.\n\n",
|
|
|
|
|
WalSegSz),
|
2018-03-21 17:14:53 +01:00
|
|
|
WalSegSz);
|
2018-05-18 05:05:27 +02:00
|
|
|
}
|
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
|
|
|
|
2002-08-18 04:48:41 +02:00
|
|
|
/*
|
2008-02-17 03:09:32 +01:00
|
|
|
* This slightly-chintzy coding will work as long as the control file
|
2009-06-11 16:49:15 +02:00
|
|
|
* timestamps are within the range of time_t; that should be the case in
|
|
|
|
|
* all foreseeable circumstances, so we don't bother importing the
|
2008-02-17 03:09:32 +01:00
|
|
|
* backend's timezone library into pg_controldata.
|
|
|
|
|
*
|
2005-10-15 04:49:52 +02:00
|
|
|
* Use variable for format to suppress overly-anal-retentive gcc warning
|
|
|
|
|
* about %c
|
2002-08-18 04:48:41 +02:00
|
|
|
*/
|
2016-03-05 20:10:19 +01:00
|
|
|
time_tmp = (time_t) ControlFile->time;
|
2002-08-18 04:48:41 +02:00
|
|
|
strftime(pgctime_str, sizeof(pgctime_str), strftime_fmt,
|
2008-02-17 03:09:32 +01:00
|
|
|
localtime(&time_tmp));
|
2016-03-05 20:10:19 +01:00
|
|
|
time_tmp = (time_t) ControlFile->checkPointCopy.time;
|
2002-08-18 04:48:41 +02:00
|
|
|
strftime(ckpttime_str, sizeof(ckpttime_str), strftime_fmt,
|
2008-02-17 03:09:32 +01:00
|
|
|
localtime(&time_tmp));
|
2004-08-29 07:07:03 +02:00
|
|
|
|
2012-07-14 13:17:43 +02:00
|
|
|
/*
|
|
|
|
|
* Calculate name of the WAL file containing the latest checkpoint's REDO
|
|
|
|
|
* start point.
|
2018-03-21 17:14:53 +01:00
|
|
|
*
|
|
|
|
|
* A corrupted control file could report a WAL segment size of 0, and to
|
|
|
|
|
* guard against division by zero, we need to treat that specially.
|
2012-07-14 13:17:43 +02:00
|
|
|
*/
|
2018-03-21 17:14:53 +01:00
|
|
|
if (WalSegSz != 0)
|
|
|
|
|
{
|
|
|
|
|
XLogSegNo segno;
|
|
|
|
|
|
|
|
|
|
XLByteToSeg(ControlFile->checkPointCopy.redo, segno, WalSegSz);
|
|
|
|
|
XLogFileName(xlogfilename, ControlFile->checkPointCopy.ThisTimeLineID,
|
|
|
|
|
segno, WalSegSz);
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
strcpy(xlogfilename, _("???"));
|
2012-07-14 13:17:43 +02:00
|
|
|
|
Support SCRAM-SHA-256 authentication (RFC 5802 and 7677).
This introduces a new generic SASL authentication method, similar to the
GSS and SSPI methods. The server first tells the client which SASL
authentication mechanism to use, and then the mechanism-specific SASL
messages are exchanged in AuthenticationSASLcontinue and PasswordMessage
messages. Only SCRAM-SHA-256 is supported at the moment, but this allows
adding more SASL mechanisms in the future, without changing the overall
protocol.
Support for channel binding, aka SCRAM-SHA-256-PLUS is left for later.
The SASLPrep algorithm, for pre-processing the password, is not yet
implemented. That could cause trouble, if you use a password with
non-ASCII characters, and a client library that does implement SASLprep.
That will hopefully be added later.
Authorization identities, as specified in the SCRAM-SHA-256 specification,
are ignored. SET SESSION AUTHORIZATION provides more or less the same
functionality, anyway.
If a user doesn't exist, perform a "mock" authentication, by constructing
an authentic-looking challenge on the fly. The challenge is derived from
a new system-wide random value, "mock authentication nonce", which is
created at initdb, and stored in the control file. We go through these
motions, in order to not give away the information on whether the user
exists, to unauthenticated users.
Bumps PG_CONTROL_VERSION, because of the new field in control file.
Patch by Michael Paquier and Heikki Linnakangas, reviewed at different
stages by Robert Haas, Stephen Frost, David Steele, Aleksander Alekseev,
and many others.
Discussion: https://www.postgresql.org/message-id/CAB7nPqRbR3GmFYdedCAhzukfKrgBLTLtMvENOmPrVWREsZkF8g%40mail.gmail.com
Discussion: https://www.postgresql.org/message-id/CAB7nPqSMXU35g%3DW9X74HVeQp0uvgJxvYOuA4A-A3M%2B0wfEBv-w%40mail.gmail.com
Discussion: https://www.postgresql.org/message-id/55192AFE.6080106@iki.fi
2017-03-07 13:25:40 +01:00
|
|
|
for (i = 0; i < MOCK_AUTH_NONCE_LEN; i++)
|
|
|
|
|
snprintf(&mock_auth_nonce_str[i * 2], 3, "%02x",
|
|
|
|
|
(unsigned char) ControlFile->mock_authentication_nonce[i]);
|
2001-03-13 02:17:40 +01:00
|
|
|
|
2006-08-07 18:57:57 +02:00
|
|
|
printf(_("pg_control version number: %u\n"),
|
2016-03-05 20:10:19 +01:00
|
|
|
ControlFile->pg_control_version);
|
2006-08-07 18:57:57 +02:00
|
|
|
printf(_("Catalog version number: %u\n"),
|
2016-03-05 20:10:19 +01:00
|
|
|
ControlFile->catalog_version_no);
|
2019-06-06 14:14:29 +02:00
|
|
|
printf(_("Database system identifier: %llu\n"),
|
|
|
|
|
(unsigned long long) ControlFile->system_identifier);
|
2006-08-07 18:57:57 +02:00
|
|
|
printf(_("Database cluster state: %s\n"),
|
2016-03-05 20:10:19 +01:00
|
|
|
dbState(ControlFile->state));
|
2006-08-07 18:57:57 +02:00
|
|
|
printf(_("pg_control last modified: %s\n"),
|
|
|
|
|
pgctime_str);
|
2002-08-22 00:24:34 +02:00
|
|
|
printf(_("Latest checkpoint location: %X/%X\n"),
|
2016-03-05 20:10:19 +01:00
|
|
|
(uint32) (ControlFile->checkPoint >> 32),
|
|
|
|
|
(uint32) ControlFile->checkPoint);
|
2002-08-22 00:24:34 +02:00
|
|
|
printf(_("Latest checkpoint's REDO location: %X/%X\n"),
|
2016-03-05 20:10:19 +01:00
|
|
|
(uint32) (ControlFile->checkPointCopy.redo >> 32),
|
|
|
|
|
(uint32) ControlFile->checkPointCopy.redo);
|
2012-07-14 13:17:43 +02:00
|
|
|
printf(_("Latest checkpoint's REDO WAL file: %s\n"),
|
|
|
|
|
xlogfilename);
|
2006-08-07 18:57:57 +02:00
|
|
|
printf(_("Latest checkpoint's TimeLineID: %u\n"),
|
2016-03-05 20:10:19 +01:00
|
|
|
ControlFile->checkPointCopy.ThisTimeLineID);
|
2013-02-11 17:13:09 +01:00
|
|
|
printf(_("Latest checkpoint's PrevTimeLineID: %u\n"),
|
2016-03-05 20:10:19 +01:00
|
|
|
ControlFile->checkPointCopy.PrevTimeLineID);
|
2012-01-25 19:02:04 +01:00
|
|
|
printf(_("Latest checkpoint's full_page_writes: %s\n"),
|
2016-03-05 20:10:19 +01:00
|
|
|
ControlFile->checkPointCopy.fullPageWrites ? _("on") : _("off"));
|
2016-02-12 23:23:59 +01:00
|
|
|
printf(_("Latest checkpoint's NextXID: %u:%u\n"),
|
2019-03-27 22:34:43 +01:00
|
|
|
EpochFromFullTransactionId(ControlFile->checkPointCopy.nextFullXid),
|
|
|
|
|
XidFromFullTransactionId(ControlFile->checkPointCopy.nextFullXid));
|
2006-08-07 18:57:57 +02:00
|
|
|
printf(_("Latest checkpoint's NextOID: %u\n"),
|
2016-03-05 20:10:19 +01:00
|
|
|
ControlFile->checkPointCopy.nextOid);
|
2006-08-07 18:57:57 +02:00
|
|
|
printf(_("Latest checkpoint's NextMultiXactId: %u\n"),
|
2016-03-05 20:10:19 +01:00
|
|
|
ControlFile->checkPointCopy.nextMulti);
|
2006-08-07 18:57:57 +02:00
|
|
|
printf(_("Latest checkpoint's NextMultiOffset: %u\n"),
|
2016-03-05 20:10:19 +01:00
|
|
|
ControlFile->checkPointCopy.nextMultiOffset);
|
2009-08-31 04:23:23 +02:00
|
|
|
printf(_("Latest checkpoint's oldestXID: %u\n"),
|
2016-03-05 20:10:19 +01:00
|
|
|
ControlFile->checkPointCopy.oldestXid);
|
2009-08-31 04:23:23 +02:00
|
|
|
printf(_("Latest checkpoint's oldestXID's DB: %u\n"),
|
2016-03-05 20:10:19 +01:00
|
|
|
ControlFile->checkPointCopy.oldestXidDB);
|
2010-01-04 13:50:50 +01:00
|
|
|
printf(_("Latest checkpoint's oldestActiveXID: %u\n"),
|
2016-03-05 20:10:19 +01:00
|
|
|
ControlFile->checkPointCopy.oldestActiveXid);
|
2013-01-24 15:52:53 +01:00
|
|
|
printf(_("Latest checkpoint's oldestMultiXid: %u\n"),
|
2016-03-05 20:10:19 +01:00
|
|
|
ControlFile->checkPointCopy.oldestMulti);
|
Improve concurrency of foreign key locking
This patch introduces two additional lock modes for tuples: "SELECT FOR
KEY SHARE" and "SELECT FOR NO KEY UPDATE". These don't block each
other, in contrast with already existing "SELECT FOR SHARE" and "SELECT
FOR UPDATE". UPDATE commands that do not modify the values stored in
the columns that are part of the key of the tuple now grab a SELECT FOR
NO KEY UPDATE lock on the tuple, allowing them to proceed concurrently
with tuple locks of the FOR KEY SHARE variety.
Foreign key triggers now use FOR KEY SHARE instead of FOR SHARE; this
means the concurrency improvement applies to them, which is the whole
point of this patch.
The added tuple lock semantics require some rejiggering of the multixact
module, so that the locking level that each transaction is holding can
be stored alongside its Xid. Also, multixacts now need to persist
across server restarts and crashes, because they can now represent not
only tuple locks, but also tuple updates. This means we need more
careful tracking of lifetime of pg_multixact SLRU files; since they now
persist longer, we require more infrastructure to figure out when they
can be removed. pg_upgrade also needs to be careful to copy
pg_multixact files over from the old server to the new, or at least part
of multixact.c state, depending on the versions of the old and new
servers.
Tuple time qualification rules (HeapTupleSatisfies routines) need to be
careful not to consider tuples with the "is multi" infomask bit set as
being only locked; they might need to look up MultiXact values (i.e.
possibly do pg_multixact I/O) to find out the Xid that updated a tuple,
whereas they previously were assured to only use information readily
available from the tuple header. This is considered acceptable, because
the extra I/O would involve cases that would previously cause some
commands to block waiting for concurrent transactions to finish.
Another important change is the fact that locking tuples that have
previously been updated causes the future versions to be marked as
locked, too; this is essential for correctness of foreign key checks.
This causes additional WAL-logging, also (there was previously a single
WAL record for a locked tuple; now there are as many as updated copies
of the tuple there exist.)
With all this in place, contention related to tuples being checked by
foreign key rules should be much reduced.
As a bonus, the old behavior that a subtransaction grabbing a stronger
tuple lock than the parent (sub)transaction held on a given tuple and
later aborting caused the weaker lock to be lost, has been fixed.
Many new spec files were added for isolation tester framework, to ensure
overall behavior is sane. There's probably room for several more tests.
There were several reviewers of this patch; in particular, Noah Misch
and Andres Freund spent considerable time in it. Original idea for the
patch came from Simon Riggs, after a problem report by Joel Jacobson.
Most code is from me, with contributions from Marti Raudsepp, Alexander
Shulgin, Noah Misch and Andres Freund.
This patch was discussed in several pgsql-hackers threads; the most
important start at the following message-ids:
AANLkTimo9XVcEzfiBR-ut3KVNDkjm2Vxh+t8kAmWjPuv@mail.gmail.com
1290721684-sup-3951@alvh.no-ip.org
1294953201-sup-2099@alvh.no-ip.org
1320343602-sup-2290@alvh.no-ip.org
1339690386-sup-8927@alvh.no-ip.org
4FE5FF020200002500048A3D@gw.wicourts.gov
4FEAB90A0200002500048B7D@gw.wicourts.gov
2013-01-23 16:04:59 +01:00
|
|
|
printf(_("Latest checkpoint's oldestMulti's DB: %u\n"),
|
2016-03-05 20:10:19 +01:00
|
|
|
ControlFile->checkPointCopy.oldestMultiDB);
|
2015-12-28 21:34:11 +01:00
|
|
|
printf(_("Latest checkpoint's oldestCommitTsXid:%u\n"),
|
2016-03-05 20:10:19 +01:00
|
|
|
ControlFile->checkPointCopy.oldestCommitTsXid);
|
2015-12-28 21:34:11 +01:00
|
|
|
printf(_("Latest checkpoint's newestCommitTsXid:%u\n"),
|
2016-03-05 20:10:19 +01:00
|
|
|
ControlFile->checkPointCopy.newestCommitTsXid);
|
2006-08-07 18:57:57 +02:00
|
|
|
printf(_("Time of latest checkpoint: %s\n"),
|
|
|
|
|
ckpttime_str);
|
2013-02-11 21:50:15 +01:00
|
|
|
printf(_("Fake LSN counter for unlogged rels: %X/%X\n"),
|
2016-03-05 20:10:19 +01:00
|
|
|
(uint32) (ControlFile->unloggedLSN >> 32),
|
|
|
|
|
(uint32) ControlFile->unloggedLSN);
|
2013-03-17 02:47:10 +01:00
|
|
|
printf(_("Minimum recovery ending location: %X/%X\n"),
|
2016-03-05 20:10:19 +01:00
|
|
|
(uint32) (ControlFile->minRecoveryPoint >> 32),
|
|
|
|
|
(uint32) ControlFile->minRecoveryPoint);
|
2012-12-04 10:24:28 +01:00
|
|
|
printf(_("Min recovery ending loc's timeline: %u\n"),
|
2016-03-05 20:10:19 +01:00
|
|
|
ControlFile->minRecoveryPointTLI);
|
2010-01-04 13:50:50 +01:00
|
|
|
printf(_("Backup start location: %X/%X\n"),
|
2016-03-05 20:10:19 +01:00
|
|
|
(uint32) (ControlFile->backupStartPoint >> 32),
|
|
|
|
|
(uint32) ControlFile->backupStartPoint);
|
2012-01-25 19:02:04 +01:00
|
|
|
printf(_("Backup end location: %X/%X\n"),
|
2016-03-05 20:10:19 +01:00
|
|
|
(uint32) (ControlFile->backupEndPoint >> 32),
|
|
|
|
|
(uint32) ControlFile->backupEndPoint);
|
2011-08-17 11:36:41 +02:00
|
|
|
printf(_("End-of-backup record required: %s\n"),
|
2016-03-05 20:10:19 +01:00
|
|
|
ControlFile->backupEndRequired ? _("yes") : _("no"));
|
2015-08-26 03:45:44 +02:00
|
|
|
printf(_("wal_level setting: %s\n"),
|
2016-03-05 20:10:19 +01:00
|
|
|
wal_level_str(ControlFile->wal_level));
|
2015-08-26 03:45:44 +02:00
|
|
|
printf(_("wal_log_hints setting: %s\n"),
|
2016-03-05 20:10:19 +01:00
|
|
|
ControlFile->wal_log_hints ? _("on") : _("off"));
|
2015-08-26 03:45:44 +02:00
|
|
|
printf(_("max_connections setting: %d\n"),
|
2016-03-05 20:10:19 +01:00
|
|
|
ControlFile->MaxConnections);
|
2015-08-26 03:45:44 +02:00
|
|
|
printf(_("max_worker_processes setting: %d\n"),
|
2016-03-05 20:10:19 +01:00
|
|
|
ControlFile->max_worker_processes);
|
Move max_wal_senders out of max_connections for connection slot handling
Since its introduction, max_wal_senders is counted as part of
max_connections when it comes to define how many connection slots can be
used for replication connections with a WAL sender context. This can
lead to confusion for some users, as it could be possible to block a
base backup or replication from happening because other backend sessions
are already taken for other purposes by an application, and
superuser-only connection slots are not a correct solution to handle
that case.
This commit makes max_wal_senders independent of max_connections for its
handling of PGPROC entries in ProcGlobal, meaning that connection slots
for WAL senders are handled using their own free queue, like autovacuum
workers and bgworkers.
One compatibility issue that this change creates is that a standby now
requires to have a value of max_wal_senders at least equal to its
primary. So, if a standby created enforces the value of
max_wal_senders to be lower than that, then this could break failovers.
Normally this should not be an issue though, as any settings of a
standby are inherited from its primary as postgresql.conf gets normally
copied as part of a base backup, so parameters would be consistent.
Author: Alexander Kukushkin
Reviewed-by: Kyotaro Horiguchi, Petr Jelínek, Masahiko Sawada, Oleksii
Kliukin
Discussion: https://postgr.es/m/CAFh8B=nBzHQeYAu0b8fjK-AF1X4+_p6GRtwG+cCgs6Vci2uRuQ@mail.gmail.com
2019-02-12 02:07:56 +01:00
|
|
|
printf(_("max_wal_senders setting: %d\n"),
|
|
|
|
|
ControlFile->max_wal_senders);
|
2015-08-26 03:45:44 +02:00
|
|
|
printf(_("max_prepared_xacts setting: %d\n"),
|
2016-03-05 20:10:19 +01:00
|
|
|
ControlFile->max_prepared_xacts);
|
2015-08-26 03:45:44 +02:00
|
|
|
printf(_("max_locks_per_xact setting: %d\n"),
|
2016-03-05 20:10:19 +01:00
|
|
|
ControlFile->max_locks_per_xact);
|
2015-08-26 03:45:44 +02:00
|
|
|
printf(_("track_commit_timestamp setting: %s\n"),
|
2016-03-05 20:10:19 +01:00
|
|
|
ControlFile->track_commit_timestamp ? _("on") : _("off"));
|
2006-08-07 18:57:57 +02:00
|
|
|
printf(_("Maximum data alignment: %u\n"),
|
2016-03-05 20:10:19 +01:00
|
|
|
ControlFile->maxAlign);
|
2005-10-03 02:28:43 +02:00
|
|
|
/* we don't print floatFormat since can't say much useful about it */
|
2006-08-07 18:57:57 +02:00
|
|
|
printf(_("Database block size: %u\n"),
|
2016-03-05 20:10:19 +01:00
|
|
|
ControlFile->blcksz);
|
2006-08-07 18:57:57 +02:00
|
|
|
printf(_("Blocks per segment of large relation: %u\n"),
|
2016-03-05 20:10:19 +01:00
|
|
|
ControlFile->relseg_size);
|
2006-08-07 18:57:57 +02:00
|
|
|
printf(_("WAL block size: %u\n"),
|
2016-03-05 20:10:19 +01:00
|
|
|
ControlFile->xlog_blcksz);
|
2006-08-07 18:57:57 +02:00
|
|
|
printf(_("Bytes per WAL segment: %u\n"),
|
2016-03-05 20:10:19 +01:00
|
|
|
ControlFile->xlog_seg_size);
|
2006-08-07 18:57:57 +02:00
|
|
|
printf(_("Maximum length of identifiers: %u\n"),
|
2016-03-05 20:10:19 +01:00
|
|
|
ControlFile->nameDataLen);
|
2006-08-07 18:57:57 +02:00
|
|
|
printf(_("Maximum columns in an index: %u\n"),
|
2016-03-05 20:10:19 +01:00
|
|
|
ControlFile->indexMaxKeys);
|
2007-04-03 06:14:26 +02:00
|
|
|
printf(_("Maximum size of a TOAST chunk: %u\n"),
|
2016-03-05 20:10:19 +01:00
|
|
|
ControlFile->toast_max_chunk_size);
|
2014-06-05 17:31:06 +02:00
|
|
|
printf(_("Size of a large-object chunk: %u\n"),
|
2016-03-05 20:10:19 +01:00
|
|
|
ControlFile->loblksize);
|
2017-02-23 18:23:12 +01:00
|
|
|
/* This is no longer configurable, but users may still expect to see it: */
|
2002-08-22 00:24:34 +02:00
|
|
|
printf(_("Date/time type storage: %s\n"),
|
2017-02-23 18:23:12 +01:00
|
|
|
_("64-bit integers"));
|
2008-04-21 02:26:47 +02:00
|
|
|
printf(_("Float8 argument passing: %s\n"),
|
2016-03-05 20:10:19 +01:00
|
|
|
(ControlFile->float8ByVal ? _("by value") : _("by reference")));
|
2013-04-30 13:27:12 +02:00
|
|
|
printf(_("Data page checksum version: %u\n"),
|
2016-03-05 20:10:19 +01:00
|
|
|
ControlFile->data_checksum_version);
|
Support SCRAM-SHA-256 authentication (RFC 5802 and 7677).
This introduces a new generic SASL authentication method, similar to the
GSS and SSPI methods. The server first tells the client which SASL
authentication mechanism to use, and then the mechanism-specific SASL
messages are exchanged in AuthenticationSASLcontinue and PasswordMessage
messages. Only SCRAM-SHA-256 is supported at the moment, but this allows
adding more SASL mechanisms in the future, without changing the overall
protocol.
Support for channel binding, aka SCRAM-SHA-256-PLUS is left for later.
The SASLPrep algorithm, for pre-processing the password, is not yet
implemented. That could cause trouble, if you use a password with
non-ASCII characters, and a client library that does implement SASLprep.
That will hopefully be added later.
Authorization identities, as specified in the SCRAM-SHA-256 specification,
are ignored. SET SESSION AUTHORIZATION provides more or less the same
functionality, anyway.
If a user doesn't exist, perform a "mock" authentication, by constructing
an authentic-looking challenge on the fly. The challenge is derived from
a new system-wide random value, "mock authentication nonce", which is
created at initdb, and stored in the control file. We go through these
motions, in order to not give away the information on whether the user
exists, to unauthenticated users.
Bumps PG_CONTROL_VERSION, because of the new field in control file.
Patch by Michael Paquier and Heikki Linnakangas, reviewed at different
stages by Robert Haas, Stephen Frost, David Steele, Aleksander Alekseev,
and many others.
Discussion: https://www.postgresql.org/message-id/CAB7nPqRbR3GmFYdedCAhzukfKrgBLTLtMvENOmPrVWREsZkF8g%40mail.gmail.com
Discussion: https://www.postgresql.org/message-id/CAB7nPqSMXU35g%3DW9X74HVeQp0uvgJxvYOuA4A-A3M%2B0wfEBv-w%40mail.gmail.com
Discussion: https://www.postgresql.org/message-id/55192AFE.6080106@iki.fi
2017-03-07 13:25:40 +01:00
|
|
|
printf(_("Mock authentication nonce: %s\n"),
|
|
|
|
|
mock_auth_nonce_str);
|
2002-08-22 00:24:34 +02:00
|
|
|
return 0;
|
2001-02-23 21:38:35 +01:00
|
|
|
}
|