2003-06-18 14:19:11 +02:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
|
|
|
* vacuumdb
|
|
|
|
*
|
2020-01-01 18:21:45 +01:00
|
|
|
* Portions Copyright (c) 1996-2020, PostgreSQL Global Development Group
|
2003-06-18 14:19:11 +02:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
|
|
|
*
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/bin/scripts/vacuumdb.c
|
2003-06-18 14:19:11 +02:00
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "postgres_fe.h"
|
2015-01-23 19:02:45 +01:00
|
|
|
|
2018-04-08 19:59:52 +02:00
|
|
|
#include "catalog/pg_class_d.h"
|
2017-03-10 04:42:16 +01:00
|
|
|
|
2003-06-18 14:19:11 +02:00
|
|
|
#include "common.h"
|
2019-05-14 20:19:49 +02:00
|
|
|
#include "common/logging.h"
|
2019-12-04 02:06:45 +01:00
|
|
|
#include "fe_utils/cancel.h"
|
Use catalog query to discover tables to process in vacuumdb
vacuumdb would use a catalog query only when the command caller does not
define a list of tables. Switching to a catalog table represents two
advantages:
- Relation existence check can happen before running any VACUUM or
ANALYZE query. Before this change, if multiple relations are defined
using --table, the utility would fail only after processing the
firstly-defined ones, which may be a long some depending on the size of
the relation. This adds checks for the relation names, and does
nothing, at least yet, for the attribute names.
- More filtering options can become available for the utility user.
These options, which may be introduced later on, are based on the
relation size or the relation age, and need to be made available even if
the user does not list any specific table with --table.
Author: Nathan Bossart
Reviewed-by: Michael Paquier, Masahiko Sawada
Discussion: https://postgr.es/m/FFE5373C-E26A-495B-B5C8-911EC4A41C5E@amazon.com
2019-01-29 03:22:03 +01:00
|
|
|
#include "fe_utils/connect.h"
|
2016-03-24 20:55:44 +01:00
|
|
|
#include "fe_utils/simple_list.h"
|
|
|
|
#include "fe_utils/string_utils.h"
|
2019-07-19 02:31:58 +02:00
|
|
|
#include "scripts_parallel.h"
|
2003-06-18 14:19:11 +02:00
|
|
|
|
|
|
|
|
2015-01-23 19:02:45 +01:00
|
|
|
/* vacuum options controlled by user flags */
|
|
|
|
typedef struct vacuumingOptions
|
|
|
|
{
|
|
|
|
bool analyze_only;
|
|
|
|
bool verbose;
|
|
|
|
bool and_analyze;
|
|
|
|
bool full;
|
|
|
|
bool freeze;
|
2019-01-08 02:52:29 +01:00
|
|
|
bool disable_page_skipping;
|
|
|
|
bool skip_locked;
|
2019-01-31 05:06:51 +01:00
|
|
|
int min_xid_age;
|
|
|
|
int min_mxid_age;
|
2020-01-29 06:38:50 +01:00
|
|
|
int parallel_workers; /* >= 0 indicates user specified the
|
|
|
|
* parallel degree, otherwise -1 */
|
2015-01-23 19:02:45 +01:00
|
|
|
} vacuumingOptions;
|
|
|
|
|
|
|
|
|
|
|
|
static void vacuum_one_database(const char *dbname, vacuumingOptions *vacopts,
|
2019-05-22 19:04:48 +02:00
|
|
|
int stage,
|
|
|
|
SimpleStringList *tables,
|
|
|
|
const char *host, const char *port,
|
|
|
|
const char *username, enum trivalue prompt_password,
|
|
|
|
int concurrentCons,
|
|
|
|
const char *progname, bool echo, bool quiet);
|
2015-01-23 19:02:45 +01:00
|
|
|
|
|
|
|
static void vacuum_all_databases(vacuumingOptions *vacopts,
|
2019-05-22 19:04:48 +02:00
|
|
|
bool analyze_in_stages,
|
|
|
|
const char *maintenance_db,
|
|
|
|
const char *host, const char *port,
|
|
|
|
const char *username, enum trivalue prompt_password,
|
|
|
|
int concurrentCons,
|
|
|
|
const char *progname, bool echo, bool quiet);
|
2003-06-18 14:19:11 +02:00
|
|
|
|
Use catalog query to discover tables to process in vacuumdb
vacuumdb would use a catalog query only when the command caller does not
define a list of tables. Switching to a catalog table represents two
advantages:
- Relation existence check can happen before running any VACUUM or
ANALYZE query. Before this change, if multiple relations are defined
using --table, the utility would fail only after processing the
firstly-defined ones, which may be a long some depending on the size of
the relation. This adds checks for the relation names, and does
nothing, at least yet, for the attribute names.
- More filtering options can become available for the utility user.
These options, which may be introduced later on, are based on the
relation size or the relation age, and need to be made available even if
the user does not list any specific table with --table.
Author: Nathan Bossart
Reviewed-by: Michael Paquier, Masahiko Sawada
Discussion: https://postgr.es/m/FFE5373C-E26A-495B-B5C8-911EC4A41C5E@amazon.com
2019-01-29 03:22:03 +01:00
|
|
|
static void prepare_vacuum_command(PQExpBuffer sql, int serverVersion,
|
2019-05-22 19:04:48 +02:00
|
|
|
vacuumingOptions *vacopts, const char *table);
|
2015-01-23 19:02:45 +01:00
|
|
|
|
|
|
|
static void run_vacuum_command(PGconn *conn, const char *sql, bool echo,
|
2019-07-23 07:29:34 +02:00
|
|
|
const char *table);
|
2015-01-23 19:02:45 +01:00
|
|
|
|
2003-06-18 14:19:11 +02:00
|
|
|
static void help(const char *progname);
|
|
|
|
|
2015-01-23 19:02:45 +01:00
|
|
|
/* For analyze-in-stages mode */
|
|
|
|
#define ANALYZE_NO_STAGE -1
|
|
|
|
#define ANALYZE_NUM_STAGES 3
|
|
|
|
|
2003-06-18 14:19:11 +02:00
|
|
|
|
|
|
|
int
|
|
|
|
main(int argc, char *argv[])
|
|
|
|
{
|
|
|
|
static struct option long_options[] = {
|
|
|
|
{"host", required_argument, NULL, 'h'},
|
|
|
|
{"port", required_argument, NULL, 'p'},
|
|
|
|
{"username", required_argument, NULL, 'U'},
|
2009-02-26 17:02:39 +01:00
|
|
|
{"no-password", no_argument, NULL, 'w'},
|
2003-06-18 14:19:11 +02:00
|
|
|
{"password", no_argument, NULL, 'W'},
|
|
|
|
{"echo", no_argument, NULL, 'e'},
|
|
|
|
{"quiet", no_argument, NULL, 'q'},
|
|
|
|
{"dbname", required_argument, NULL, 'd'},
|
|
|
|
{"analyze", no_argument, NULL, 'z'},
|
2010-01-07 15:35:44 +01:00
|
|
|
{"analyze-only", no_argument, NULL, 'Z'},
|
2009-02-18 13:11:55 +01:00
|
|
|
{"freeze", no_argument, NULL, 'F'},
|
2003-06-18 14:19:11 +02:00
|
|
|
{"all", no_argument, NULL, 'a'},
|
|
|
|
{"table", required_argument, NULL, 't'},
|
|
|
|
{"full", no_argument, NULL, 'f'},
|
|
|
|
{"verbose", no_argument, NULL, 'v'},
|
2015-01-23 19:02:45 +01:00
|
|
|
{"jobs", required_argument, NULL, 'j'},
|
2020-01-29 06:38:50 +01:00
|
|
|
{"parallel", required_argument, NULL, 'P'},
|
2011-12-06 14:48:15 +01:00
|
|
|
{"maintenance-db", required_argument, NULL, 2},
|
2014-04-15 05:15:05 +02:00
|
|
|
{"analyze-in-stages", no_argument, NULL, 3},
|
2019-01-08 02:52:29 +01:00
|
|
|
{"disable-page-skipping", no_argument, NULL, 4},
|
|
|
|
{"skip-locked", no_argument, NULL, 5},
|
2019-01-31 05:06:51 +01:00
|
|
|
{"min-xid-age", required_argument, NULL, 6},
|
|
|
|
{"min-mxid-age", required_argument, NULL, 7},
|
2003-06-18 14:19:11 +02:00
|
|
|
{NULL, 0, NULL, 0}
|
|
|
|
};
|
|
|
|
|
2004-05-12 15:38:49 +02:00
|
|
|
const char *progname;
|
2003-06-18 14:19:11 +02:00
|
|
|
int optindex;
|
|
|
|
int c;
|
|
|
|
const char *dbname = NULL;
|
2011-12-06 14:48:15 +01:00
|
|
|
const char *maintenance_db = NULL;
|
2003-06-18 14:19:11 +02:00
|
|
|
char *host = NULL;
|
|
|
|
char *port = NULL;
|
|
|
|
char *username = NULL;
|
2009-02-26 17:02:39 +01:00
|
|
|
enum trivalue prompt_password = TRI_DEFAULT;
|
2003-06-18 14:19:11 +02:00
|
|
|
bool echo = false;
|
|
|
|
bool quiet = false;
|
2015-01-23 19:02:45 +01:00
|
|
|
vacuumingOptions vacopts;
|
2014-04-15 05:15:05 +02:00
|
|
|
bool analyze_in_stages = false;
|
2003-06-18 14:19:11 +02:00
|
|
|
bool alldb = false;
|
2013-01-17 11:24:47 +01:00
|
|
|
SimpleStringList tables = {NULL, NULL};
|
2015-01-23 19:02:45 +01:00
|
|
|
int concurrentCons = 1;
|
|
|
|
int tbl_count = 0;
|
|
|
|
|
|
|
|
/* initialize options to all false */
|
|
|
|
memset(&vacopts, 0, sizeof(vacopts));
|
2020-01-29 06:38:50 +01:00
|
|
|
vacopts.parallel_workers = -1;
|
2003-06-18 14:19:11 +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]);
|
2003-06-18 14:19:11 +02:00
|
|
|
progname = get_progname(argv[0]);
|
2008-12-11 08:34:09 +01:00
|
|
|
set_pglocale_pgservice(argv[0], PG_TEXTDOMAIN("pgscripts"));
|
2004-06-01 04:54:09 +02:00
|
|
|
|
2003-06-18 14:19:11 +02:00
|
|
|
handle_help_version_opts(argc, argv, "vacuumdb", help);
|
|
|
|
|
2020-01-29 06:38:50 +01:00
|
|
|
while ((c = getopt_long(argc, argv, "h:p:U:wWeqd:zZFat:fvj:P:", long_options, &optindex)) != -1)
|
2003-06-18 14:19:11 +02:00
|
|
|
{
|
|
|
|
switch (c)
|
|
|
|
{
|
|
|
|
case 'h':
|
2012-10-12 19:35:40 +02:00
|
|
|
host = pg_strdup(optarg);
|
2003-06-18 14:19:11 +02:00
|
|
|
break;
|
|
|
|
case 'p':
|
2012-10-12 19:35:40 +02:00
|
|
|
port = pg_strdup(optarg);
|
2003-06-18 14:19:11 +02:00
|
|
|
break;
|
|
|
|
case 'U':
|
2012-10-12 19:35:40 +02:00
|
|
|
username = pg_strdup(optarg);
|
2003-06-18 14:19:11 +02:00
|
|
|
break;
|
2009-02-26 17:02:39 +01:00
|
|
|
case 'w':
|
|
|
|
prompt_password = TRI_NO;
|
|
|
|
break;
|
2003-06-18 14:19:11 +02:00
|
|
|
case 'W':
|
2009-02-26 17:02:39 +01:00
|
|
|
prompt_password = TRI_YES;
|
2003-06-18 14:19:11 +02:00
|
|
|
break;
|
|
|
|
case 'e':
|
|
|
|
echo = true;
|
|
|
|
break;
|
|
|
|
case 'q':
|
|
|
|
quiet = true;
|
|
|
|
break;
|
|
|
|
case 'd':
|
2012-10-12 19:35:40 +02:00
|
|
|
dbname = pg_strdup(optarg);
|
2003-06-18 14:19:11 +02:00
|
|
|
break;
|
|
|
|
case 'z':
|
2015-01-23 19:02:45 +01:00
|
|
|
vacopts.and_analyze = true;
|
2010-01-06 03:59:46 +01:00
|
|
|
break;
|
2010-01-07 15:35:44 +01:00
|
|
|
case 'Z':
|
2015-01-23 19:02:45 +01:00
|
|
|
vacopts.analyze_only = true;
|
2003-06-18 14:19:11 +02:00
|
|
|
break;
|
2009-02-18 13:11:55 +01:00
|
|
|
case 'F':
|
2015-01-23 19:02:45 +01:00
|
|
|
vacopts.freeze = true;
|
2009-02-18 13:11:55 +01:00
|
|
|
break;
|
2003-06-18 14:19:11 +02:00
|
|
|
case 'a':
|
|
|
|
alldb = true;
|
|
|
|
break;
|
|
|
|
case 't':
|
2015-01-23 19:02:45 +01:00
|
|
|
{
|
|
|
|
simple_string_list_append(&tables, optarg);
|
|
|
|
tbl_count++;
|
|
|
|
break;
|
|
|
|
}
|
2003-06-18 14:19:11 +02:00
|
|
|
case 'f':
|
2015-01-23 19:02:45 +01:00
|
|
|
vacopts.full = true;
|
2003-06-18 14:19:11 +02:00
|
|
|
break;
|
|
|
|
case 'v':
|
2015-01-23 19:02:45 +01:00
|
|
|
vacopts.verbose = true;
|
|
|
|
break;
|
|
|
|
case 'j':
|
|
|
|
concurrentCons = atoi(optarg);
|
|
|
|
if (concurrentCons <= 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("number of parallel jobs must be at least 1");
|
2015-01-23 19:02:45 +01:00
|
|
|
exit(1);
|
|
|
|
}
|
2003-06-18 14:19:11 +02:00
|
|
|
break;
|
2020-01-29 06:38:50 +01:00
|
|
|
case 'P':
|
|
|
|
vacopts.parallel_workers = atoi(optarg);
|
|
|
|
if (vacopts.parallel_workers < 0)
|
|
|
|
{
|
|
|
|
pg_log_error("parallel vacuum degree must be a non-negative integer");
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
break;
|
2011-12-06 14:48:15 +01:00
|
|
|
case 2:
|
2012-10-12 19:35:40 +02:00
|
|
|
maintenance_db = pg_strdup(optarg);
|
2011-12-06 14:48:15 +01:00
|
|
|
break;
|
2014-04-15 05:15:05 +02:00
|
|
|
case 3:
|
2015-01-23 19:02:45 +01:00
|
|
|
analyze_in_stages = vacopts.analyze_only = true;
|
2014-04-15 05:15:05 +02:00
|
|
|
break;
|
2019-01-08 02:52:29 +01:00
|
|
|
case 4:
|
|
|
|
vacopts.disable_page_skipping = true;
|
|
|
|
break;
|
|
|
|
case 5:
|
|
|
|
vacopts.skip_locked = true;
|
|
|
|
break;
|
2019-01-31 05:06:51 +01:00
|
|
|
case 6:
|
|
|
|
vacopts.min_xid_age = atoi(optarg);
|
|
|
|
if (vacopts.min_xid_age <= 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("minimum transaction ID age must be at least 1");
|
2019-01-31 05:06:51 +01:00
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case 7:
|
|
|
|
vacopts.min_mxid_age = atoi(optarg);
|
|
|
|
if (vacopts.min_mxid_age <= 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("minimum multixact ID age must be at least 1");
|
2019-01-31 05:06:51 +01:00
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
break;
|
2003-06-18 14:19:11 +02:00
|
|
|
default:
|
2003-07-23 10:47:41 +02:00
|
|
|
fprintf(stderr, _("Try \"%s --help\" for more information.\n"), progname);
|
2003-06-18 14:19:11 +02:00
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-06-10 21:20:04 +02:00
|
|
|
/*
|
|
|
|
* Non-option argument specifies database name as long as it wasn't
|
|
|
|
* already specified with -d / --dbname
|
2012-04-18 00:30:34 +02:00
|
|
|
*/
|
|
|
|
if (optind < argc && dbname == NULL)
|
2003-06-18 14:19:11 +02:00
|
|
|
{
|
2012-04-18 00:30:34 +02:00
|
|
|
dbname = argv[optind];
|
|
|
|
optind++;
|
|
|
|
}
|
|
|
|
|
|
|
|
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]);
|
2012-04-18 00:30:34 +02:00
|
|
|
fprintf(stderr, _("Try \"%s --help\" for more information.\n"), progname);
|
|
|
|
exit(1);
|
2003-06-18 14:19:11 +02:00
|
|
|
}
|
|
|
|
|
2015-01-23 19:02:45 +01:00
|
|
|
if (vacopts.analyze_only)
|
2010-01-06 03:59:46 +01:00
|
|
|
{
|
2015-01-23 19:02:45 +01:00
|
|
|
if (vacopts.full)
|
2010-01-06 03:59:46 +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 use the \"%s\" option when performing only analyze",
|
|
|
|
"full");
|
2010-01-06 03:59:46 +01:00
|
|
|
exit(1);
|
|
|
|
}
|
2015-01-23 19:02:45 +01:00
|
|
|
if (vacopts.freeze)
|
2010-01-06 03:59:46 +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 use the \"%s\" option when performing only analyze",
|
|
|
|
"freeze");
|
2010-01-06 03:59:46 +01:00
|
|
|
exit(1);
|
|
|
|
}
|
2019-01-08 02:52:29 +01:00
|
|
|
if (vacopts.disable_page_skipping)
|
|
|
|
{
|
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 use the \"%s\" option when performing only analyze",
|
|
|
|
"disable-page-skipping");
|
2019-01-08 02:52:29 +01:00
|
|
|
exit(1);
|
|
|
|
}
|
2010-01-07 13:38:55 +01:00
|
|
|
/* allow 'and_analyze' with 'analyze_only' */
|
2010-01-06 03:59:46 +01:00
|
|
|
}
|
|
|
|
|
2020-01-29 06:38:50 +01:00
|
|
|
/* Prohibit full and analyze_only options with parallel option */
|
|
|
|
if (vacopts.parallel_workers >= 0)
|
|
|
|
{
|
|
|
|
if (vacopts.analyze_only)
|
|
|
|
{
|
|
|
|
pg_log_error("cannot use the \"%s\" option when performing only analyze",
|
|
|
|
"parallel");
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
if (vacopts.full)
|
|
|
|
{
|
|
|
|
pg_log_error("cannot use the \"%s\" option when performing full",
|
|
|
|
"parallel");
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-12-02 03:18:56 +01:00
|
|
|
setup_cancel_handler(NULL);
|
2010-01-06 06:31:14 +01:00
|
|
|
|
2015-01-23 19:02:45 +01:00
|
|
|
/* Avoid opening extra connections. */
|
|
|
|
if (tbl_count && (concurrentCons > tbl_count))
|
|
|
|
concurrentCons = tbl_count;
|
|
|
|
|
2003-06-18 14:19:11 +02:00
|
|
|
if (alldb)
|
|
|
|
{
|
|
|
|
if (dbname)
|
|
|
|
{
|
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 vacuum all databases and a specific one at the same time");
|
2003-06-18 14:19:11 +02:00
|
|
|
exit(1);
|
|
|
|
}
|
2013-01-17 11:24:47 +01:00
|
|
|
if (tables.head != NULL)
|
2003-06-18 14:19:11 +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("cannot vacuum specific table(s) in all databases");
|
2003-06-18 14:19:11 +02:00
|
|
|
exit(1);
|
|
|
|
}
|
2003-08-04 02:43:34 +02:00
|
|
|
|
2015-01-23 19:02:45 +01:00
|
|
|
vacuum_all_databases(&vacopts,
|
|
|
|
analyze_in_stages,
|
|
|
|
maintenance_db,
|
|
|
|
host, port, username, prompt_password,
|
|
|
|
concurrentCons,
|
|
|
|
progname, echo, quiet);
|
2003-06-18 14:19:11 +02:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
if (dbname == NULL)
|
|
|
|
{
|
|
|
|
if (getenv("PGDATABASE"))
|
|
|
|
dbname = getenv("PGDATABASE");
|
|
|
|
else if (getenv("PGUSER"))
|
|
|
|
dbname = getenv("PGUSER");
|
|
|
|
else
|
2013-12-18 18:16:16 +01:00
|
|
|
dbname = get_user_name_or_exit(progname);
|
2003-06-18 14:19:11 +02:00
|
|
|
}
|
|
|
|
|
2015-01-23 19:02:45 +01:00
|
|
|
if (analyze_in_stages)
|
2013-01-17 11:24:47 +01:00
|
|
|
{
|
2015-01-23 19:02:45 +01:00
|
|
|
int stage;
|
2013-01-17 11:24:47 +01:00
|
|
|
|
2015-01-23 19:02:45 +01:00
|
|
|
for (stage = 0; stage < ANALYZE_NUM_STAGES; stage++)
|
2013-01-17 11:24:47 +01:00
|
|
|
{
|
2015-01-23 19:02:45 +01:00
|
|
|
vacuum_one_database(dbname, &vacopts,
|
|
|
|
stage,
|
|
|
|
&tables,
|
2013-01-17 11:24:47 +01:00
|
|
|
host, port, username, prompt_password,
|
2015-01-23 19:02:45 +01:00
|
|
|
concurrentCons,
|
2015-12-23 21:45:43 +01:00
|
|
|
progname, echo, quiet);
|
2013-01-17 11:24:47 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
2015-01-23 19:02:45 +01:00
|
|
|
vacuum_one_database(dbname, &vacopts,
|
|
|
|
ANALYZE_NO_STAGE,
|
|
|
|
&tables,
|
2013-01-17 11:24:47 +01:00
|
|
|
host, port, username, prompt_password,
|
2015-01-23 19:02:45 +01:00
|
|
|
concurrentCons,
|
2015-12-23 21:45:43 +01:00
|
|
|
progname, echo, quiet);
|
2003-06-18 14:19:11 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
exit(0);
|
|
|
|
}
|
|
|
|
|
2015-01-23 19:02:45 +01:00
|
|
|
/*
|
|
|
|
* vacuum_one_database
|
|
|
|
*
|
|
|
|
* Process tables in the given database. If the 'tables' list is empty,
|
|
|
|
* process all tables in the database.
|
|
|
|
*
|
|
|
|
* Note that this function is only concerned with running exactly one stage
|
|
|
|
* when in analyze-in-stages mode; caller must iterate on us if necessary.
|
|
|
|
*
|
|
|
|
* If concurrentCons is > 1, multiple connections are used to vacuum tables
|
|
|
|
* in parallel. In this case and if the table list is empty, we first obtain
|
|
|
|
* a list of tables from the database.
|
|
|
|
*/
|
2014-04-15 05:15:05 +02:00
|
|
|
static void
|
2015-01-23 19:02:45 +01:00
|
|
|
vacuum_one_database(const char *dbname, vacuumingOptions *vacopts,
|
|
|
|
int stage,
|
|
|
|
SimpleStringList *tables,
|
|
|
|
const char *host, const char *port,
|
2015-12-23 21:45:43 +01:00
|
|
|
const char *username, enum trivalue prompt_password,
|
2015-01-23 19:02:45 +01:00
|
|
|
int concurrentCons,
|
2015-12-23 21:45:43 +01:00
|
|
|
const char *progname, bool echo, bool quiet)
|
2014-04-15 05:15:05 +02:00
|
|
|
{
|
2015-01-23 19:02:45 +01:00
|
|
|
PQExpBufferData sql;
|
Use catalog query to discover tables to process in vacuumdb
vacuumdb would use a catalog query only when the command caller does not
define a list of tables. Switching to a catalog table represents two
advantages:
- Relation existence check can happen before running any VACUUM or
ANALYZE query. Before this change, if multiple relations are defined
using --table, the utility would fail only after processing the
firstly-defined ones, which may be a long some depending on the size of
the relation. This adds checks for the relation names, and does
nothing, at least yet, for the attribute names.
- More filtering options can become available for the utility user.
These options, which may be introduced later on, are based on the
relation size or the relation age, and need to be made available even if
the user does not list any specific table with --table.
Author: Nathan Bossart
Reviewed-by: Michael Paquier, Masahiko Sawada
Discussion: https://postgr.es/m/FFE5373C-E26A-495B-B5C8-911EC4A41C5E@amazon.com
2019-01-29 03:22:03 +01:00
|
|
|
PQExpBufferData buf;
|
|
|
|
PQExpBufferData catalog_query;
|
|
|
|
PGresult *res;
|
2015-01-23 19:02:45 +01:00
|
|
|
PGconn *conn;
|
|
|
|
SimpleStringListCell *cell;
|
Fix assorted issues in parallel vacuumdb.
Avoid storing the result of PQsocket() in a pgsocket variable; it's
declared as int, and the no-socket test is properly written as "x < 0"
not "x == PGINVALID_SOCKET". This accidentally had no bad effect
because we never got to init_slot() with a bad connection, but it's
still wrong.
Actually, it seems like we should avoid storing the result for a long
period at all. The function's not so expensive that it's worth avoiding,
and the existing coding technique here would fail if anyone tried to
PQreset the connection during the life of the program. Hence, just
re-call PQsocket every time we construct a select(2) mask.
Speaking of select(), GetIdleSlot imagined that it could compute the
select mask once and continue to use it over multiple calls to
select_loop(), which is pretty bogus since that would stomp on the
mask on return. This could only matter if the function's outer loop
iterated more than once, which is unlikely (it'd take some connection
receiving data, but not enough to complete its command). But if it
did happen, we'd acquire "tunnel vision" and stop watching the other
connections for query termination, with the effect of losing parallelism.
Another way in which GetIdleSlot could lose parallelism is that once
PQisBusy returns false, it would lock in on that connection and do
PQgetResult until that returns NULL; in some cases that could result
in blocking. (Perhaps this can never happen in vacuumdb due to the
limited set of commands that it can issue, but I'm not quite sure
of that, and even if true today it's not a future-proof assumption.)
Refactor the code to do that properly, so that it risks blocking in
PQgetResult only in cases where we need to wait anyway.
Another loss-of-parallelism problem, which *is* easily demonstrable,
is that any setup queries issued during prepare_vacuum_command() were
always issued on the last-to-be-created connection, whether or not
that was idle. Long-running operations on that connection thus
prevented issuance of additional operations on the other ones, except
in the limited cases where no preparatory query was needed. Instead,
wait till we've identified a free connection and use that one.
Also, avoid core dump due to undersized malloc request in the case
that no tables are identified to be vacuumed.
The bogus no-socket test was noted by CharSyam, the other problems
identified in my own code review. Back-patch to 9.5 where parallel
vacuumdb was introduced.
Discussion: https://postgr.es/m/CAMrLSE6etb33-192DTEUGkV-TsvEcxtBDxGWG1tgNOMnQHwgDA@mail.gmail.com
2018-03-31 22:28:52 +02:00
|
|
|
ParallelSlot *slots;
|
2015-01-23 19:02:45 +01:00
|
|
|
SimpleStringList dbtables = {NULL, NULL};
|
|
|
|
int i;
|
Use catalog query to discover tables to process in vacuumdb
vacuumdb would use a catalog query only when the command caller does not
define a list of tables. Switching to a catalog table represents two
advantages:
- Relation existence check can happen before running any VACUUM or
ANALYZE query. Before this change, if multiple relations are defined
using --table, the utility would fail only after processing the
firstly-defined ones, which may be a long some depending on the size of
the relation. This adds checks for the relation names, and does
nothing, at least yet, for the attribute names.
- More filtering options can become available for the utility user.
These options, which may be introduced later on, are based on the
relation size or the relation age, and need to be made available even if
the user does not list any specific table with --table.
Author: Nathan Bossart
Reviewed-by: Michael Paquier, Masahiko Sawada
Discussion: https://postgr.es/m/FFE5373C-E26A-495B-B5C8-911EC4A41C5E@amazon.com
2019-01-29 03:22:03 +01:00
|
|
|
int ntups;
|
2015-08-12 16:49:36 +02:00
|
|
|
bool failed = false;
|
2015-01-23 19:02:45 +01:00
|
|
|
bool parallel = concurrentCons > 1;
|
Use catalog query to discover tables to process in vacuumdb
vacuumdb would use a catalog query only when the command caller does not
define a list of tables. Switching to a catalog table represents two
advantages:
- Relation existence check can happen before running any VACUUM or
ANALYZE query. Before this change, if multiple relations are defined
using --table, the utility would fail only after processing the
firstly-defined ones, which may be a long some depending on the size of
the relation. This adds checks for the relation names, and does
nothing, at least yet, for the attribute names.
- More filtering options can become available for the utility user.
These options, which may be introduced later on, are based on the
relation size or the relation age, and need to be made available even if
the user does not list any specific table with --table.
Author: Nathan Bossart
Reviewed-by: Michael Paquier, Masahiko Sawada
Discussion: https://postgr.es/m/FFE5373C-E26A-495B-B5C8-911EC4A41C5E@amazon.com
2019-01-29 03:22:03 +01:00
|
|
|
bool tables_listed = false;
|
2019-01-31 05:06:51 +01:00
|
|
|
bool has_where = false;
|
2015-01-23 19:02:45 +01:00
|
|
|
const char *stage_commands[] = {
|
|
|
|
"SET default_statistics_target=1; SET vacuum_cost_delay=0;",
|
|
|
|
"SET default_statistics_target=10; RESET vacuum_cost_delay;",
|
|
|
|
"RESET default_statistics_target;"
|
|
|
|
};
|
|
|
|
const char *stage_messages[] = {
|
|
|
|
gettext_noop("Generating minimal optimizer statistics (1 target)"),
|
|
|
|
gettext_noop("Generating medium optimizer statistics (10 targets)"),
|
|
|
|
gettext_noop("Generating default (full) optimizer statistics")
|
|
|
|
};
|
|
|
|
|
|
|
|
Assert(stage == ANALYZE_NO_STAGE ||
|
|
|
|
(stage >= 0 && stage < ANALYZE_NUM_STAGES));
|
|
|
|
|
2016-08-08 16:07:46 +02:00
|
|
|
conn = connectDatabase(dbname, host, port, username, prompt_password,
|
Empty search_path in Autovacuum and non-psql/pgbench clients.
This makes the client programs behave as documented regardless of the
connect-time search_path and regardless of user-created objects. Today,
a malicious user with CREATE permission on a search_path schema can take
control of certain of these clients' queries and invoke arbitrary SQL
functions under the client identity, often a superuser. This is
exploitable in the default configuration, where all users have CREATE
privilege on schema "public".
This changes behavior of user-defined code stored in the database, like
pg_index.indexprs and pg_extension_config_dump(). If they reach code
bearing unqualified names, "does not exist" or "no schema has been
selected to create in" errors might appear. Users may fix such errors
by schema-qualifying affected names. After upgrading, consider watching
server logs for these errors.
The --table arguments of src/bin/scripts clients have been lax; for
example, "vacuumdb -Zt pg_am\;CHECKPOINT" performed a checkpoint. That
now fails, but for now, "vacuumdb -Zt 'pg_am(amname);CHECKPOINT'" still
performs a checkpoint.
Back-patch to 9.3 (all supported versions).
Reviewed by Tom Lane, though this fix strategy was not his first choice.
Reported by Arseniy Sharoglazov.
Security: CVE-2018-1058
2018-02-26 16:39:44 +01:00
|
|
|
progname, echo, false, true);
|
2016-08-08 16:07:46 +02:00
|
|
|
|
2019-01-08 02:52:29 +01:00
|
|
|
if (vacopts->disable_page_skipping && PQserverVersion(conn) < 90600)
|
|
|
|
{
|
|
|
|
PQfinish(conn);
|
2019-04-29 16:05:07 +02:00
|
|
|
pg_log_error("cannot use the \"%s\" option on server versions older than PostgreSQL %s",
|
|
|
|
"disable-page-skipping", "9.6");
|
2019-01-08 02:52:29 +01:00
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (vacopts->skip_locked && PQserverVersion(conn) < 120000)
|
|
|
|
{
|
|
|
|
PQfinish(conn);
|
2019-04-29 16:05:07 +02:00
|
|
|
pg_log_error("cannot use the \"%s\" option on server versions older than PostgreSQL %s",
|
|
|
|
"skip-locked", "12");
|
2019-01-08 02:52:29 +01:00
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
2019-01-31 05:06:51 +01:00
|
|
|
if (vacopts->min_xid_age != 0 && PQserverVersion(conn) < 90600)
|
|
|
|
{
|
2019-04-29 16:05:07 +02:00
|
|
|
pg_log_error("cannot use the \"%s\" option on server versions older than PostgreSQL %s",
|
|
|
|
"--min-xid-age", "9.6");
|
2019-01-31 05:06:51 +01:00
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (vacopts->min_mxid_age != 0 && PQserverVersion(conn) < 90600)
|
|
|
|
{
|
2019-04-29 16:05:07 +02:00
|
|
|
pg_log_error("cannot use the \"%s\" option on server versions older than PostgreSQL %s",
|
|
|
|
"--min-mxid-age", "9.6");
|
2019-01-31 05:06:51 +01:00
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
2020-01-29 06:38:50 +01:00
|
|
|
if (vacopts->parallel_workers >= 0 && PQserverVersion(conn) < 130000)
|
|
|
|
{
|
|
|
|
pg_log_error("cannot use the \"%s\" option on server versions older than PostgreSQL %s",
|
|
|
|
"--parallel", "13");
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
2015-01-23 19:02:45 +01:00
|
|
|
if (!quiet)
|
2014-04-15 05:15:05 +02:00
|
|
|
{
|
2015-01-23 19:02:45 +01:00
|
|
|
if (stage != ANALYZE_NO_STAGE)
|
2016-08-08 16:07:46 +02:00
|
|
|
printf(_("%s: processing database \"%s\": %s\n"),
|
2018-08-21 08:17:13 +02:00
|
|
|
progname, PQdb(conn), _(stage_messages[stage]));
|
2014-04-15 05:15:05 +02:00
|
|
|
else
|
2016-08-08 16:07:46 +02:00
|
|
|
printf(_("%s: vacuuming database \"%s\"\n"),
|
|
|
|
progname, PQdb(conn));
|
2015-01-23 19:02:45 +01:00
|
|
|
fflush(stdout);
|
2014-04-15 05:15:05 +02:00
|
|
|
}
|
|
|
|
|
2015-01-23 19:02:45 +01:00
|
|
|
/*
|
Use catalog query to discover tables to process in vacuumdb
vacuumdb would use a catalog query only when the command caller does not
define a list of tables. Switching to a catalog table represents two
advantages:
- Relation existence check can happen before running any VACUUM or
ANALYZE query. Before this change, if multiple relations are defined
using --table, the utility would fail only after processing the
firstly-defined ones, which may be a long some depending on the size of
the relation. This adds checks for the relation names, and does
nothing, at least yet, for the attribute names.
- More filtering options can become available for the utility user.
These options, which may be introduced later on, are based on the
relation size or the relation age, and need to be made available even if
the user does not list any specific table with --table.
Author: Nathan Bossart
Reviewed-by: Michael Paquier, Masahiko Sawada
Discussion: https://postgr.es/m/FFE5373C-E26A-495B-B5C8-911EC4A41C5E@amazon.com
2019-01-29 03:22:03 +01:00
|
|
|
* Prepare the list of tables to process by querying the catalogs.
|
|
|
|
*
|
|
|
|
* Since we execute the constructed query with the default search_path
|
|
|
|
* (which could be unsafe), everything in this query MUST be fully
|
|
|
|
* qualified.
|
|
|
|
*
|
|
|
|
* First, build a WITH clause for the catalog query if any tables were
|
|
|
|
* specified, with a set of values made of relation names and their
|
|
|
|
* optional set of columns. This is used to match any provided column
|
|
|
|
* lists with the generated qualified identifiers and to filter for the
|
|
|
|
* tables provided via --table. If a listed table does not exist, the
|
|
|
|
* catalog query will fail.
|
2015-01-23 19:02:45 +01:00
|
|
|
*/
|
Use catalog query to discover tables to process in vacuumdb
vacuumdb would use a catalog query only when the command caller does not
define a list of tables. Switching to a catalog table represents two
advantages:
- Relation existence check can happen before running any VACUUM or
ANALYZE query. Before this change, if multiple relations are defined
using --table, the utility would fail only after processing the
firstly-defined ones, which may be a long some depending on the size of
the relation. This adds checks for the relation names, and does
nothing, at least yet, for the attribute names.
- More filtering options can become available for the utility user.
These options, which may be introduced later on, are based on the
relation size or the relation age, and need to be made available even if
the user does not list any specific table with --table.
Author: Nathan Bossart
Reviewed-by: Michael Paquier, Masahiko Sawada
Discussion: https://postgr.es/m/FFE5373C-E26A-495B-B5C8-911EC4A41C5E@amazon.com
2019-01-29 03:22:03 +01:00
|
|
|
initPQExpBuffer(&catalog_query);
|
|
|
|
for (cell = tables ? tables->head : NULL; cell; cell = cell->next)
|
2015-01-23 19:02:45 +01:00
|
|
|
{
|
Use catalog query to discover tables to process in vacuumdb
vacuumdb would use a catalog query only when the command caller does not
define a list of tables. Switching to a catalog table represents two
advantages:
- Relation existence check can happen before running any VACUUM or
ANALYZE query. Before this change, if multiple relations are defined
using --table, the utility would fail only after processing the
firstly-defined ones, which may be a long some depending on the size of
the relation. This adds checks for the relation names, and does
nothing, at least yet, for the attribute names.
- More filtering options can become available for the utility user.
These options, which may be introduced later on, are based on the
relation size or the relation age, and need to be made available even if
the user does not list any specific table with --table.
Author: Nathan Bossart
Reviewed-by: Michael Paquier, Masahiko Sawada
Discussion: https://postgr.es/m/FFE5373C-E26A-495B-B5C8-911EC4A41C5E@amazon.com
2019-01-29 03:22:03 +01:00
|
|
|
char *just_table;
|
|
|
|
const char *just_columns;
|
2015-01-23 19:02:45 +01:00
|
|
|
|
Use catalog query to discover tables to process in vacuumdb
vacuumdb would use a catalog query only when the command caller does not
define a list of tables. Switching to a catalog table represents two
advantages:
- Relation existence check can happen before running any VACUUM or
ANALYZE query. Before this change, if multiple relations are defined
using --table, the utility would fail only after processing the
firstly-defined ones, which may be a long some depending on the size of
the relation. This adds checks for the relation names, and does
nothing, at least yet, for the attribute names.
- More filtering options can become available for the utility user.
These options, which may be introduced later on, are based on the
relation size or the relation age, and need to be made available even if
the user does not list any specific table with --table.
Author: Nathan Bossart
Reviewed-by: Michael Paquier, Masahiko Sawada
Discussion: https://postgr.es/m/FFE5373C-E26A-495B-B5C8-911EC4A41C5E@amazon.com
2019-01-29 03:22:03 +01:00
|
|
|
/*
|
|
|
|
* Split relation and column names given by the user, this is used to
|
|
|
|
* feed the CTE with values on which are performed pre-run validity
|
|
|
|
* checks as well. For now these happen only on the relation name.
|
|
|
|
*/
|
|
|
|
splitTableColumnsSpec(cell->val, PQclientEncoding(conn),
|
|
|
|
&just_table, &just_columns);
|
|
|
|
|
|
|
|
if (!tables_listed)
|
|
|
|
{
|
2019-07-04 03:01:13 +02:00
|
|
|
appendPQExpBufferStr(&catalog_query,
|
|
|
|
"WITH listed_tables (table_oid, column_list) "
|
|
|
|
"AS (\n VALUES (");
|
Use catalog query to discover tables to process in vacuumdb
vacuumdb would use a catalog query only when the command caller does not
define a list of tables. Switching to a catalog table represents two
advantages:
- Relation existence check can happen before running any VACUUM or
ANALYZE query. Before this change, if multiple relations are defined
using --table, the utility would fail only after processing the
firstly-defined ones, which may be a long some depending on the size of
the relation. This adds checks for the relation names, and does
nothing, at least yet, for the attribute names.
- More filtering options can become available for the utility user.
These options, which may be introduced later on, are based on the
relation size or the relation age, and need to be made available even if
the user does not list any specific table with --table.
Author: Nathan Bossart
Reviewed-by: Michael Paquier, Masahiko Sawada
Discussion: https://postgr.es/m/FFE5373C-E26A-495B-B5C8-911EC4A41C5E@amazon.com
2019-01-29 03:22:03 +01:00
|
|
|
tables_listed = true;
|
2015-01-23 19:02:45 +01:00
|
|
|
}
|
Use catalog query to discover tables to process in vacuumdb
vacuumdb would use a catalog query only when the command caller does not
define a list of tables. Switching to a catalog table represents two
advantages:
- Relation existence check can happen before running any VACUUM or
ANALYZE query. Before this change, if multiple relations are defined
using --table, the utility would fail only after processing the
firstly-defined ones, which may be a long some depending on the size of
the relation. This adds checks for the relation names, and does
nothing, at least yet, for the attribute names.
- More filtering options can become available for the utility user.
These options, which may be introduced later on, are based on the
relation size or the relation age, and need to be made available even if
the user does not list any specific table with --table.
Author: Nathan Bossart
Reviewed-by: Michael Paquier, Masahiko Sawada
Discussion: https://postgr.es/m/FFE5373C-E26A-495B-B5C8-911EC4A41C5E@amazon.com
2019-01-29 03:22:03 +01:00
|
|
|
else
|
2019-07-04 03:01:13 +02:00
|
|
|
appendPQExpBufferStr(&catalog_query, ",\n (");
|
2015-01-23 19:02:45 +01:00
|
|
|
|
Use catalog query to discover tables to process in vacuumdb
vacuumdb would use a catalog query only when the command caller does not
define a list of tables. Switching to a catalog table represents two
advantages:
- Relation existence check can happen before running any VACUUM or
ANALYZE query. Before this change, if multiple relations are defined
using --table, the utility would fail only after processing the
firstly-defined ones, which may be a long some depending on the size of
the relation. This adds checks for the relation names, and does
nothing, at least yet, for the attribute names.
- More filtering options can become available for the utility user.
These options, which may be introduced later on, are based on the
relation size or the relation age, and need to be made available even if
the user does not list any specific table with --table.
Author: Nathan Bossart
Reviewed-by: Michael Paquier, Masahiko Sawada
Discussion: https://postgr.es/m/FFE5373C-E26A-495B-B5C8-911EC4A41C5E@amazon.com
2019-01-29 03:22:03 +01:00
|
|
|
appendStringLiteralConn(&catalog_query, just_table, conn);
|
2019-07-04 03:01:13 +02:00
|
|
|
appendPQExpBufferStr(&catalog_query, "::pg_catalog.regclass, ");
|
2015-01-23 19:02:45 +01:00
|
|
|
|
Use catalog query to discover tables to process in vacuumdb
vacuumdb would use a catalog query only when the command caller does not
define a list of tables. Switching to a catalog table represents two
advantages:
- Relation existence check can happen before running any VACUUM or
ANALYZE query. Before this change, if multiple relations are defined
using --table, the utility would fail only after processing the
firstly-defined ones, which may be a long some depending on the size of
the relation. This adds checks for the relation names, and does
nothing, at least yet, for the attribute names.
- More filtering options can become available for the utility user.
These options, which may be introduced later on, are based on the
relation size or the relation age, and need to be made available even if
the user does not list any specific table with --table.
Author: Nathan Bossart
Reviewed-by: Michael Paquier, Masahiko Sawada
Discussion: https://postgr.es/m/FFE5373C-E26A-495B-B5C8-911EC4A41C5E@amazon.com
2019-01-29 03:22:03 +01:00
|
|
|
if (just_columns && just_columns[0] != '\0')
|
|
|
|
appendStringLiteralConn(&catalog_query, just_columns, conn);
|
|
|
|
else
|
|
|
|
appendPQExpBufferStr(&catalog_query, "NULL");
|
|
|
|
|
|
|
|
appendPQExpBufferStr(&catalog_query, "::pg_catalog.text)");
|
|
|
|
|
|
|
|
pg_free(just_table);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Finish formatting the CTE */
|
|
|
|
if (tables_listed)
|
2019-07-04 03:01:13 +02:00
|
|
|
appendPQExpBufferStr(&catalog_query, "\n)\n");
|
Use catalog query to discover tables to process in vacuumdb
vacuumdb would use a catalog query only when the command caller does not
define a list of tables. Switching to a catalog table represents two
advantages:
- Relation existence check can happen before running any VACUUM or
ANALYZE query. Before this change, if multiple relations are defined
using --table, the utility would fail only after processing the
firstly-defined ones, which may be a long some depending on the size of
the relation. This adds checks for the relation names, and does
nothing, at least yet, for the attribute names.
- More filtering options can become available for the utility user.
These options, which may be introduced later on, are based on the
relation size or the relation age, and need to be made available even if
the user does not list any specific table with --table.
Author: Nathan Bossart
Reviewed-by: Michael Paquier, Masahiko Sawada
Discussion: https://postgr.es/m/FFE5373C-E26A-495B-B5C8-911EC4A41C5E@amazon.com
2019-01-29 03:22:03 +01:00
|
|
|
|
2019-07-04 03:01:13 +02:00
|
|
|
appendPQExpBufferStr(&catalog_query, "SELECT c.relname, ns.nspname");
|
Use catalog query to discover tables to process in vacuumdb
vacuumdb would use a catalog query only when the command caller does not
define a list of tables. Switching to a catalog table represents two
advantages:
- Relation existence check can happen before running any VACUUM or
ANALYZE query. Before this change, if multiple relations are defined
using --table, the utility would fail only after processing the
firstly-defined ones, which may be a long some depending on the size of
the relation. This adds checks for the relation names, and does
nothing, at least yet, for the attribute names.
- More filtering options can become available for the utility user.
These options, which may be introduced later on, are based on the
relation size or the relation age, and need to be made available even if
the user does not list any specific table with --table.
Author: Nathan Bossart
Reviewed-by: Michael Paquier, Masahiko Sawada
Discussion: https://postgr.es/m/FFE5373C-E26A-495B-B5C8-911EC4A41C5E@amazon.com
2019-01-29 03:22:03 +01:00
|
|
|
|
|
|
|
if (tables_listed)
|
2019-07-04 03:01:13 +02:00
|
|
|
appendPQExpBufferStr(&catalog_query, ", listed_tables.column_list");
|
Use catalog query to discover tables to process in vacuumdb
vacuumdb would use a catalog query only when the command caller does not
define a list of tables. Switching to a catalog table represents two
advantages:
- Relation existence check can happen before running any VACUUM or
ANALYZE query. Before this change, if multiple relations are defined
using --table, the utility would fail only after processing the
firstly-defined ones, which may be a long some depending on the size of
the relation. This adds checks for the relation names, and does
nothing, at least yet, for the attribute names.
- More filtering options can become available for the utility user.
These options, which may be introduced later on, are based on the
relation size or the relation age, and need to be made available even if
the user does not list any specific table with --table.
Author: Nathan Bossart
Reviewed-by: Michael Paquier, Masahiko Sawada
Discussion: https://postgr.es/m/FFE5373C-E26A-495B-B5C8-911EC4A41C5E@amazon.com
2019-01-29 03:22:03 +01:00
|
|
|
|
2019-07-04 03:01:13 +02:00
|
|
|
appendPQExpBufferStr(&catalog_query,
|
|
|
|
" FROM pg_catalog.pg_class c\n"
|
|
|
|
" JOIN pg_catalog.pg_namespace ns"
|
|
|
|
" ON c.relnamespace OPERATOR(pg_catalog.=) ns.oid\n"
|
|
|
|
" LEFT JOIN pg_catalog.pg_class t"
|
|
|
|
" ON c.reltoastrelid OPERATOR(pg_catalog.=) t.oid\n");
|
Use catalog query to discover tables to process in vacuumdb
vacuumdb would use a catalog query only when the command caller does not
define a list of tables. Switching to a catalog table represents two
advantages:
- Relation existence check can happen before running any VACUUM or
ANALYZE query. Before this change, if multiple relations are defined
using --table, the utility would fail only after processing the
firstly-defined ones, which may be a long some depending on the size of
the relation. This adds checks for the relation names, and does
nothing, at least yet, for the attribute names.
- More filtering options can become available for the utility user.
These options, which may be introduced later on, are based on the
relation size or the relation age, and need to be made available even if
the user does not list any specific table with --table.
Author: Nathan Bossart
Reviewed-by: Michael Paquier, Masahiko Sawada
Discussion: https://postgr.es/m/FFE5373C-E26A-495B-B5C8-911EC4A41C5E@amazon.com
2019-01-29 03:22:03 +01:00
|
|
|
|
|
|
|
/* Used to match the tables listed by the user */
|
|
|
|
if (tables_listed)
|
2019-07-04 03:01:13 +02:00
|
|
|
appendPQExpBufferStr(&catalog_query, " JOIN listed_tables"
|
|
|
|
" ON listed_tables.table_oid OPERATOR(pg_catalog.=) c.oid\n");
|
Use catalog query to discover tables to process in vacuumdb
vacuumdb would use a catalog query only when the command caller does not
define a list of tables. Switching to a catalog table represents two
advantages:
- Relation existence check can happen before running any VACUUM or
ANALYZE query. Before this change, if multiple relations are defined
using --table, the utility would fail only after processing the
firstly-defined ones, which may be a long some depending on the size of
the relation. This adds checks for the relation names, and does
nothing, at least yet, for the attribute names.
- More filtering options can become available for the utility user.
These options, which may be introduced later on, are based on the
relation size or the relation age, and need to be made available even if
the user does not list any specific table with --table.
Author: Nathan Bossart
Reviewed-by: Michael Paquier, Masahiko Sawada
Discussion: https://postgr.es/m/FFE5373C-E26A-495B-B5C8-911EC4A41C5E@amazon.com
2019-01-29 03:22:03 +01:00
|
|
|
|
2019-01-30 01:44:08 +01:00
|
|
|
/*
|
|
|
|
* If no tables were listed, filter for the relevant relation types. If
|
|
|
|
* tables were given via --table, don't bother filtering by relation type.
|
|
|
|
* Instead, let the server decide whether a given relation can be
|
|
|
|
* processed in which case the user will know about it.
|
|
|
|
*/
|
|
|
|
if (!tables_listed)
|
2019-01-31 05:06:51 +01:00
|
|
|
{
|
2019-07-04 03:01:13 +02:00
|
|
|
appendPQExpBufferStr(&catalog_query, " WHERE c.relkind OPERATOR(pg_catalog.=) ANY (array["
|
|
|
|
CppAsString2(RELKIND_RELATION) ", "
|
|
|
|
CppAsString2(RELKIND_MATVIEW) "])\n");
|
2019-01-31 05:06:51 +01:00
|
|
|
has_where = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* For --min-xid-age and --min-mxid-age, the age of the relation is the
|
|
|
|
* greatest of the ages of the main relation and its associated TOAST
|
|
|
|
* table. The commands generated by vacuumdb will also process the TOAST
|
|
|
|
* table for the relation if necessary, so it does not need to be
|
|
|
|
* considered separately.
|
|
|
|
*/
|
|
|
|
if (vacopts->min_xid_age != 0)
|
|
|
|
{
|
|
|
|
appendPQExpBuffer(&catalog_query,
|
|
|
|
" %s GREATEST(pg_catalog.age(c.relfrozenxid),"
|
|
|
|
" pg_catalog.age(t.relfrozenxid)) "
|
|
|
|
" OPERATOR(pg_catalog.>=) '%d'::pg_catalog.int4\n"
|
|
|
|
" AND c.relfrozenxid OPERATOR(pg_catalog.!=)"
|
|
|
|
" '0'::pg_catalog.xid\n",
|
|
|
|
has_where ? "AND" : "WHERE", vacopts->min_xid_age);
|
|
|
|
has_where = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (vacopts->min_mxid_age != 0)
|
|
|
|
{
|
|
|
|
appendPQExpBuffer(&catalog_query,
|
|
|
|
" %s GREATEST(pg_catalog.mxid_age(c.relminmxid),"
|
|
|
|
" pg_catalog.mxid_age(t.relminmxid)) OPERATOR(pg_catalog.>=)"
|
|
|
|
" '%d'::pg_catalog.int4\n"
|
|
|
|
" AND c.relminmxid OPERATOR(pg_catalog.!=)"
|
|
|
|
" '0'::pg_catalog.xid\n",
|
|
|
|
has_where ? "AND" : "WHERE", vacopts->min_mxid_age);
|
|
|
|
has_where = true;
|
|
|
|
}
|
Use catalog query to discover tables to process in vacuumdb
vacuumdb would use a catalog query only when the command caller does not
define a list of tables. Switching to a catalog table represents two
advantages:
- Relation existence check can happen before running any VACUUM or
ANALYZE query. Before this change, if multiple relations are defined
using --table, the utility would fail only after processing the
firstly-defined ones, which may be a long some depending on the size of
the relation. This adds checks for the relation names, and does
nothing, at least yet, for the attribute names.
- More filtering options can become available for the utility user.
These options, which may be introduced later on, are based on the
relation size or the relation age, and need to be made available even if
the user does not list any specific table with --table.
Author: Nathan Bossart
Reviewed-by: Michael Paquier, Masahiko Sawada
Discussion: https://postgr.es/m/FFE5373C-E26A-495B-B5C8-911EC4A41C5E@amazon.com
2019-01-29 03:22:03 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Execute the catalog query. We use the default search_path for this
|
|
|
|
* query for consistency with table lookups done elsewhere by the user.
|
|
|
|
*/
|
2019-07-04 03:01:13 +02:00
|
|
|
appendPQExpBufferStr(&catalog_query, " ORDER BY c.relpages DESC;");
|
2019-07-19 02:31:58 +02:00
|
|
|
executeCommand(conn, "RESET search_path;", echo);
|
|
|
|
res = executeQuery(conn, catalog_query.data, echo);
|
Use catalog query to discover tables to process in vacuumdb
vacuumdb would use a catalog query only when the command caller does not
define a list of tables. Switching to a catalog table represents two
advantages:
- Relation existence check can happen before running any VACUUM or
ANALYZE query. Before this change, if multiple relations are defined
using --table, the utility would fail only after processing the
firstly-defined ones, which may be a long some depending on the size of
the relation. This adds checks for the relation names, and does
nothing, at least yet, for the attribute names.
- More filtering options can become available for the utility user.
These options, which may be introduced later on, are based on the
relation size or the relation age, and need to be made available even if
the user does not list any specific table with --table.
Author: Nathan Bossart
Reviewed-by: Michael Paquier, Masahiko Sawada
Discussion: https://postgr.es/m/FFE5373C-E26A-495B-B5C8-911EC4A41C5E@amazon.com
2019-01-29 03:22:03 +01:00
|
|
|
termPQExpBuffer(&catalog_query);
|
2019-07-19 02:31:58 +02:00
|
|
|
PQclear(executeQuery(conn, ALWAYS_SECURE_SEARCH_PATH_SQL, echo));
|
Use catalog query to discover tables to process in vacuumdb
vacuumdb would use a catalog query only when the command caller does not
define a list of tables. Switching to a catalog table represents two
advantages:
- Relation existence check can happen before running any VACUUM or
ANALYZE query. Before this change, if multiple relations are defined
using --table, the utility would fail only after processing the
firstly-defined ones, which may be a long some depending on the size of
the relation. This adds checks for the relation names, and does
nothing, at least yet, for the attribute names.
- More filtering options can become available for the utility user.
These options, which may be introduced later on, are based on the
relation size or the relation age, and need to be made available even if
the user does not list any specific table with --table.
Author: Nathan Bossart
Reviewed-by: Michael Paquier, Masahiko Sawada
Discussion: https://postgr.es/m/FFE5373C-E26A-495B-B5C8-911EC4A41C5E@amazon.com
2019-01-29 03:22:03 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If no rows are returned, there are no matching tables, so we are done.
|
|
|
|
*/
|
|
|
|
ntups = PQntuples(res);
|
|
|
|
if (ntups == 0)
|
|
|
|
{
|
|
|
|
PQclear(res);
|
|
|
|
PQfinish(conn);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Build qualified identifiers for each table, including the column list
|
|
|
|
* if given.
|
|
|
|
*/
|
|
|
|
initPQExpBuffer(&buf);
|
|
|
|
for (i = 0; i < ntups; i++)
|
|
|
|
{
|
|
|
|
appendPQExpBufferStr(&buf,
|
|
|
|
fmtQualifiedId(PQgetvalue(res, i, 1),
|
|
|
|
PQgetvalue(res, i, 0)));
|
|
|
|
|
|
|
|
if (tables_listed && !PQgetisnull(res, i, 2))
|
|
|
|
appendPQExpBufferStr(&buf, PQgetvalue(res, i, 2));
|
|
|
|
|
|
|
|
simple_string_list_append(&dbtables, buf.data);
|
|
|
|
resetPQExpBuffer(&buf);
|
|
|
|
}
|
|
|
|
termPQExpBuffer(&buf);
|
|
|
|
PQclear(res);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If there are more connections than vacuumable relations, we don't need
|
|
|
|
* to use them all.
|
|
|
|
*/
|
|
|
|
if (parallel)
|
|
|
|
{
|
2015-01-23 19:02:45 +01:00
|
|
|
if (concurrentCons > ntups)
|
|
|
|
concurrentCons = ntups;
|
|
|
|
if (concurrentCons <= 1)
|
|
|
|
parallel = false;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Setup the database connections. We reuse the connection we already have
|
|
|
|
* for the first slot. If not in parallel mode, the first slot in the
|
|
|
|
* array contains the connection.
|
|
|
|
*/
|
Fix assorted issues in parallel vacuumdb.
Avoid storing the result of PQsocket() in a pgsocket variable; it's
declared as int, and the no-socket test is properly written as "x < 0"
not "x == PGINVALID_SOCKET". This accidentally had no bad effect
because we never got to init_slot() with a bad connection, but it's
still wrong.
Actually, it seems like we should avoid storing the result for a long
period at all. The function's not so expensive that it's worth avoiding,
and the existing coding technique here would fail if anyone tried to
PQreset the connection during the life of the program. Hence, just
re-call PQsocket every time we construct a select(2) mask.
Speaking of select(), GetIdleSlot imagined that it could compute the
select mask once and continue to use it over multiple calls to
select_loop(), which is pretty bogus since that would stomp on the
mask on return. This could only matter if the function's outer loop
iterated more than once, which is unlikely (it'd take some connection
receiving data, but not enough to complete its command). But if it
did happen, we'd acquire "tunnel vision" and stop watching the other
connections for query termination, with the effect of losing parallelism.
Another way in which GetIdleSlot could lose parallelism is that once
PQisBusy returns false, it would lock in on that connection and do
PQgetResult until that returns NULL; in some cases that could result
in blocking. (Perhaps this can never happen in vacuumdb due to the
limited set of commands that it can issue, but I'm not quite sure
of that, and even if true today it's not a future-proof assumption.)
Refactor the code to do that properly, so that it risks blocking in
PQgetResult only in cases where we need to wait anyway.
Another loss-of-parallelism problem, which *is* easily demonstrable,
is that any setup queries issued during prepare_vacuum_command() were
always issued on the last-to-be-created connection, whether or not
that was idle. Long-running operations on that connection thus
prevented issuance of additional operations on the other ones, except
in the limited cases where no preparatory query was needed. Instead,
wait till we've identified a free connection and use that one.
Also, avoid core dump due to undersized malloc request in the case
that no tables are identified to be vacuumed.
The bogus no-socket test was noted by CharSyam, the other problems
identified in my own code review. Back-patch to 9.5 where parallel
vacuumdb was introduced.
Discussion: https://postgr.es/m/CAMrLSE6etb33-192DTEUGkV-TsvEcxtBDxGWG1tgNOMnQHwgDA@mail.gmail.com
2018-03-31 22:28:52 +02:00
|
|
|
if (concurrentCons <= 0)
|
|
|
|
concurrentCons = 1;
|
2019-07-19 02:31:58 +02:00
|
|
|
|
|
|
|
slots = ParallelSlotsSetup(dbname, host, port, username, prompt_password,
|
|
|
|
progname, echo, conn, concurrentCons);
|
2015-01-23 19:02:45 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Prepare all the connections to run the appropriate analyze stage, if
|
|
|
|
* caller requested that mode.
|
|
|
|
*/
|
|
|
|
if (stage != ANALYZE_NO_STAGE)
|
|
|
|
{
|
|
|
|
int j;
|
|
|
|
|
|
|
|
/* We already emitted the message above */
|
|
|
|
|
|
|
|
for (j = 0; j < concurrentCons; j++)
|
|
|
|
executeCommand((slots + j)->connection,
|
2019-07-19 02:31:58 +02:00
|
|
|
stage_commands[stage], echo);
|
2015-01-23 19:02:45 +01:00
|
|
|
}
|
|
|
|
|
Use catalog query to discover tables to process in vacuumdb
vacuumdb would use a catalog query only when the command caller does not
define a list of tables. Switching to a catalog table represents two
advantages:
- Relation existence check can happen before running any VACUUM or
ANALYZE query. Before this change, if multiple relations are defined
using --table, the utility would fail only after processing the
firstly-defined ones, which may be a long some depending on the size of
the relation. This adds checks for the relation names, and does
nothing, at least yet, for the attribute names.
- More filtering options can become available for the utility user.
These options, which may be introduced later on, are based on the
relation size or the relation age, and need to be made available even if
the user does not list any specific table with --table.
Author: Nathan Bossart
Reviewed-by: Michael Paquier, Masahiko Sawada
Discussion: https://postgr.es/m/FFE5373C-E26A-495B-B5C8-911EC4A41C5E@amazon.com
2019-01-29 03:22:03 +01:00
|
|
|
initPQExpBuffer(&sql);
|
|
|
|
|
|
|
|
cell = dbtables.head;
|
2015-01-23 19:02:45 +01:00
|
|
|
do
|
|
|
|
{
|
Use catalog query to discover tables to process in vacuumdb
vacuumdb would use a catalog query only when the command caller does not
define a list of tables. Switching to a catalog table represents two
advantages:
- Relation existence check can happen before running any VACUUM or
ANALYZE query. Before this change, if multiple relations are defined
using --table, the utility would fail only after processing the
firstly-defined ones, which may be a long some depending on the size of
the relation. This adds checks for the relation names, and does
nothing, at least yet, for the attribute names.
- More filtering options can become available for the utility user.
These options, which may be introduced later on, are based on the
relation size or the relation age, and need to be made available even if
the user does not list any specific table with --table.
Author: Nathan Bossart
Reviewed-by: Michael Paquier, Masahiko Sawada
Discussion: https://postgr.es/m/FFE5373C-E26A-495B-B5C8-911EC4A41C5E@amazon.com
2019-01-29 03:22:03 +01:00
|
|
|
const char *tabname = cell->val;
|
Fix assorted issues in parallel vacuumdb.
Avoid storing the result of PQsocket() in a pgsocket variable; it's
declared as int, and the no-socket test is properly written as "x < 0"
not "x == PGINVALID_SOCKET". This accidentally had no bad effect
because we never got to init_slot() with a bad connection, but it's
still wrong.
Actually, it seems like we should avoid storing the result for a long
period at all. The function's not so expensive that it's worth avoiding,
and the existing coding technique here would fail if anyone tried to
PQreset the connection during the life of the program. Hence, just
re-call PQsocket every time we construct a select(2) mask.
Speaking of select(), GetIdleSlot imagined that it could compute the
select mask once and continue to use it over multiple calls to
select_loop(), which is pretty bogus since that would stomp on the
mask on return. This could only matter if the function's outer loop
iterated more than once, which is unlikely (it'd take some connection
receiving data, but not enough to complete its command). But if it
did happen, we'd acquire "tunnel vision" and stop watching the other
connections for query termination, with the effect of losing parallelism.
Another way in which GetIdleSlot could lose parallelism is that once
PQisBusy returns false, it would lock in on that connection and do
PQgetResult until that returns NULL; in some cases that could result
in blocking. (Perhaps this can never happen in vacuumdb due to the
limited set of commands that it can issue, but I'm not quite sure
of that, and even if true today it's not a future-proof assumption.)
Refactor the code to do that properly, so that it risks blocking in
PQgetResult only in cases where we need to wait anyway.
Another loss-of-parallelism problem, which *is* easily demonstrable,
is that any setup queries issued during prepare_vacuum_command() were
always issued on the last-to-be-created connection, whether or not
that was idle. Long-running operations on that connection thus
prevented issuance of additional operations on the other ones, except
in the limited cases where no preparatory query was needed. Instead,
wait till we've identified a free connection and use that one.
Also, avoid core dump due to undersized malloc request in the case
that no tables are identified to be vacuumed.
The bogus no-socket test was noted by CharSyam, the other problems
identified in my own code review. Back-patch to 9.5 where parallel
vacuumdb was introduced.
Discussion: https://postgr.es/m/CAMrLSE6etb33-192DTEUGkV-TsvEcxtBDxGWG1tgNOMnQHwgDA@mail.gmail.com
2018-03-31 22:28:52 +02:00
|
|
|
ParallelSlot *free_slot;
|
2015-01-23 19:02:45 +01:00
|
|
|
|
|
|
|
if (CancelRequested)
|
|
|
|
{
|
2015-08-12 16:49:36 +02:00
|
|
|
failed = true;
|
2015-01-23 19:02:45 +01:00
|
|
|
goto finish;
|
|
|
|
}
|
|
|
|
|
2019-07-19 02:31:58 +02:00
|
|
|
free_slot = ParallelSlotsGetIdle(slots, concurrentCons);
|
|
|
|
if (!free_slot)
|
2015-01-23 19:02:45 +01:00
|
|
|
{
|
2019-07-19 02:31:58 +02:00
|
|
|
failed = true;
|
|
|
|
goto finish;
|
2015-01-23 19:02:45 +01:00
|
|
|
}
|
|
|
|
|
Use catalog query to discover tables to process in vacuumdb
vacuumdb would use a catalog query only when the command caller does not
define a list of tables. Switching to a catalog table represents two
advantages:
- Relation existence check can happen before running any VACUUM or
ANALYZE query. Before this change, if multiple relations are defined
using --table, the utility would fail only after processing the
firstly-defined ones, which may be a long some depending on the size of
the relation. This adds checks for the relation names, and does
nothing, at least yet, for the attribute names.
- More filtering options can become available for the utility user.
These options, which may be introduced later on, are based on the
relation size or the relation age, and need to be made available even if
the user does not list any specific table with --table.
Author: Nathan Bossart
Reviewed-by: Michael Paquier, Masahiko Sawada
Discussion: https://postgr.es/m/FFE5373C-E26A-495B-B5C8-911EC4A41C5E@amazon.com
2019-01-29 03:22:03 +01:00
|
|
|
prepare_vacuum_command(&sql, PQserverVersion(free_slot->connection),
|
|
|
|
vacopts, tabname);
|
Fix assorted issues in parallel vacuumdb.
Avoid storing the result of PQsocket() in a pgsocket variable; it's
declared as int, and the no-socket test is properly written as "x < 0"
not "x == PGINVALID_SOCKET". This accidentally had no bad effect
because we never got to init_slot() with a bad connection, but it's
still wrong.
Actually, it seems like we should avoid storing the result for a long
period at all. The function's not so expensive that it's worth avoiding,
and the existing coding technique here would fail if anyone tried to
PQreset the connection during the life of the program. Hence, just
re-call PQsocket every time we construct a select(2) mask.
Speaking of select(), GetIdleSlot imagined that it could compute the
select mask once and continue to use it over multiple calls to
select_loop(), which is pretty bogus since that would stomp on the
mask on return. This could only matter if the function's outer loop
iterated more than once, which is unlikely (it'd take some connection
receiving data, but not enough to complete its command). But if it
did happen, we'd acquire "tunnel vision" and stop watching the other
connections for query termination, with the effect of losing parallelism.
Another way in which GetIdleSlot could lose parallelism is that once
PQisBusy returns false, it would lock in on that connection and do
PQgetResult until that returns NULL; in some cases that could result
in blocking. (Perhaps this can never happen in vacuumdb due to the
limited set of commands that it can issue, but I'm not quite sure
of that, and even if true today it's not a future-proof assumption.)
Refactor the code to do that properly, so that it risks blocking in
PQgetResult only in cases where we need to wait anyway.
Another loss-of-parallelism problem, which *is* easily demonstrable,
is that any setup queries issued during prepare_vacuum_command() were
always issued on the last-to-be-created connection, whether or not
that was idle. Long-running operations on that connection thus
prevented issuance of additional operations on the other ones, except
in the limited cases where no preparatory query was needed. Instead,
wait till we've identified a free connection and use that one.
Also, avoid core dump due to undersized malloc request in the case
that no tables are identified to be vacuumed.
The bogus no-socket test was noted by CharSyam, the other problems
identified in my own code review. Back-patch to 9.5 where parallel
vacuumdb was introduced.
Discussion: https://postgr.es/m/CAMrLSE6etb33-192DTEUGkV-TsvEcxtBDxGWG1tgNOMnQHwgDA@mail.gmail.com
2018-03-31 22:28:52 +02:00
|
|
|
|
2015-03-23 19:57:11 +01:00
|
|
|
/*
|
2019-07-19 02:31:58 +02:00
|
|
|
* Execute the vacuum. All errors are handled in processQueryResult
|
|
|
|
* through ParallelSlotsGetIdle.
|
2015-03-23 19:57:11 +01:00
|
|
|
*/
|
2015-01-23 19:02:45 +01:00
|
|
|
run_vacuum_command(free_slot->connection, sql.data,
|
2019-07-23 07:29:34 +02:00
|
|
|
echo, tabname);
|
2015-01-23 19:02:45 +01:00
|
|
|
|
Use catalog query to discover tables to process in vacuumdb
vacuumdb would use a catalog query only when the command caller does not
define a list of tables. Switching to a catalog table represents two
advantages:
- Relation existence check can happen before running any VACUUM or
ANALYZE query. Before this change, if multiple relations are defined
using --table, the utility would fail only after processing the
firstly-defined ones, which may be a long some depending on the size of
the relation. This adds checks for the relation names, and does
nothing, at least yet, for the attribute names.
- More filtering options can become available for the utility user.
These options, which may be introduced later on, are based on the
relation size or the relation age, and need to be made available even if
the user does not list any specific table with --table.
Author: Nathan Bossart
Reviewed-by: Michael Paquier, Masahiko Sawada
Discussion: https://postgr.es/m/FFE5373C-E26A-495B-B5C8-911EC4A41C5E@amazon.com
2019-01-29 03:22:03 +01:00
|
|
|
cell = cell->next;
|
2015-01-23 19:02:45 +01:00
|
|
|
} while (cell != NULL);
|
|
|
|
|
2019-07-19 02:31:58 +02:00
|
|
|
if (!ParallelSlotsWaitCompletion(slots, concurrentCons))
|
|
|
|
failed = true;
|
2015-01-23 19:02:45 +01:00
|
|
|
|
|
|
|
finish:
|
2019-07-19 02:31:58 +02:00
|
|
|
ParallelSlotsTerminate(slots, concurrentCons);
|
|
|
|
pg_free(slots);
|
2015-01-23 19:02:45 +01:00
|
|
|
|
|
|
|
termPQExpBuffer(&sql);
|
|
|
|
|
2015-08-12 16:49:36 +02:00
|
|
|
if (failed)
|
2015-01-23 19:02:45 +01:00
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Vacuum/analyze all connectable databases.
|
|
|
|
*
|
|
|
|
* In analyze-in-stages mode, we process all databases in one stage before
|
|
|
|
* moving on to the next stage. That ensure minimal stats are available
|
|
|
|
* quickly everywhere before generating more detailed ones.
|
|
|
|
*/
|
2004-01-01 20:27:15 +01:00
|
|
|
static void
|
2015-01-23 19:02:45 +01:00
|
|
|
vacuum_all_databases(vacuumingOptions *vacopts,
|
|
|
|
bool analyze_in_stages,
|
|
|
|
const char *maintenance_db, const char *host,
|
|
|
|
const char *port, const char *username,
|
|
|
|
enum trivalue prompt_password,
|
|
|
|
int concurrentCons,
|
|
|
|
const char *progname, bool echo, bool quiet)
|
2003-06-18 14:19:11 +02:00
|
|
|
{
|
|
|
|
PGconn *conn;
|
2015-01-23 19:02:45 +01:00
|
|
|
PGresult *result;
|
2016-08-08 16:07:46 +02:00
|
|
|
PQExpBufferData connstr;
|
2015-01-23 19:02:45 +01:00
|
|
|
int stage;
|
|
|
|
int i;
|
2003-06-18 14:19:11 +02:00
|
|
|
|
Empty search_path in Autovacuum and non-psql/pgbench clients.
This makes the client programs behave as documented regardless of the
connect-time search_path and regardless of user-created objects. Today,
a malicious user with CREATE permission on a search_path schema can take
control of certain of these clients' queries and invoke arbitrary SQL
functions under the client identity, often a superuser. This is
exploitable in the default configuration, where all users have CREATE
privilege on schema "public".
This changes behavior of user-defined code stored in the database, like
pg_index.indexprs and pg_extension_config_dump(). If they reach code
bearing unqualified names, "does not exist" or "no schema has been
selected to create in" errors might appear. Users may fix such errors
by schema-qualifying affected names. After upgrading, consider watching
server logs for these errors.
The --table arguments of src/bin/scripts clients have been lax; for
example, "vacuumdb -Zt pg_am\;CHECKPOINT" performed a checkpoint. That
now fails, but for now, "vacuumdb -Zt 'pg_am(amname);CHECKPOINT'" still
performs a checkpoint.
Back-patch to 9.3 (all supported versions).
Reviewed by Tom Lane, though this fix strategy was not his first choice.
Reported by Arseniy Sharoglazov.
Security: CVE-2018-1058
2018-02-26 16:39:44 +01:00
|
|
|
conn = connectMaintenanceDatabase(maintenance_db, host, port, username,
|
|
|
|
prompt_password, progname, echo);
|
2015-01-23 19:02:45 +01:00
|
|
|
result = executeQuery(conn,
|
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
|
|
|
"SELECT datname FROM pg_database WHERE datallowconn ORDER BY 1;",
|
2019-07-19 02:31:58 +02:00
|
|
|
echo);
|
2015-01-23 19:02:45 +01:00
|
|
|
PQfinish(conn);
|
2003-06-18 14:19:11 +02:00
|
|
|
|
2016-08-08 16:07:46 +02:00
|
|
|
initPQExpBuffer(&connstr);
|
2015-01-23 19:02:45 +01:00
|
|
|
if (analyze_in_stages)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* When analyzing all databases in stages, we analyze them all in the
|
|
|
|
* fastest stage first, so that initial statistics become available
|
|
|
|
* for all of them as soon as possible.
|
|
|
|
*
|
|
|
|
* This means we establish several times as many connections, but
|
|
|
|
* that's a secondary consideration.
|
|
|
|
*/
|
|
|
|
for (stage = 0; stage < ANALYZE_NUM_STAGES; stage++)
|
|
|
|
{
|
|
|
|
for (i = 0; i < PQntuples(result); i++)
|
|
|
|
{
|
2016-08-08 16:07:46 +02:00
|
|
|
resetPQExpBuffer(&connstr);
|
2019-07-04 03:01:13 +02:00
|
|
|
appendPQExpBufferStr(&connstr, "dbname=");
|
2016-08-08 16:07:46 +02:00
|
|
|
appendConnStrVal(&connstr, PQgetvalue(result, i, 0));
|
2015-01-23 19:02:45 +01:00
|
|
|
|
2016-08-08 16:07:46 +02:00
|
|
|
vacuum_one_database(connstr.data, vacopts,
|
2015-01-23 19:02:45 +01:00
|
|
|
stage,
|
|
|
|
NULL,
|
|
|
|
host, port, username, prompt_password,
|
|
|
|
concurrentCons,
|
2015-12-23 21:45:43 +01:00
|
|
|
progname, echo, quiet);
|
2015-01-23 19:02:45 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
for (i = 0; i < PQntuples(result); i++)
|
|
|
|
{
|
2016-08-08 16:07:46 +02:00
|
|
|
resetPQExpBuffer(&connstr);
|
2019-07-04 03:01:13 +02:00
|
|
|
appendPQExpBufferStr(&connstr, "dbname=");
|
2016-08-08 16:07:46 +02:00
|
|
|
appendConnStrVal(&connstr, PQgetvalue(result, i, 0));
|
2010-01-06 06:31:14 +01:00
|
|
|
|
2016-08-08 16:07:46 +02:00
|
|
|
vacuum_one_database(connstr.data, vacopts,
|
2015-01-23 19:02:45 +01:00
|
|
|
ANALYZE_NO_STAGE,
|
|
|
|
NULL,
|
|
|
|
host, port, username, prompt_password,
|
|
|
|
concurrentCons,
|
2015-12-23 21:45:43 +01:00
|
|
|
progname, echo, quiet);
|
2015-01-23 19:02:45 +01:00
|
|
|
}
|
|
|
|
}
|
2016-08-08 16:07:46 +02:00
|
|
|
termPQExpBuffer(&connstr);
|
2015-01-23 19:02:45 +01:00
|
|
|
|
|
|
|
PQclear(result);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Construct a vacuum/analyze command to run based on the given options, in the
|
|
|
|
* given string buffer, which may contain previous garbage.
|
|
|
|
*
|
Use catalog query to discover tables to process in vacuumdb
vacuumdb would use a catalog query only when the command caller does not
define a list of tables. Switching to a catalog table represents two
advantages:
- Relation existence check can happen before running any VACUUM or
ANALYZE query. Before this change, if multiple relations are defined
using --table, the utility would fail only after processing the
firstly-defined ones, which may be a long some depending on the size of
the relation. This adds checks for the relation names, and does
nothing, at least yet, for the attribute names.
- More filtering options can become available for the utility user.
These options, which may be introduced later on, are based on the
relation size or the relation age, and need to be made available even if
the user does not list any specific table with --table.
Author: Nathan Bossart
Reviewed-by: Michael Paquier, Masahiko Sawada
Discussion: https://postgr.es/m/FFE5373C-E26A-495B-B5C8-911EC4A41C5E@amazon.com
2019-01-29 03:22:03 +01:00
|
|
|
* The table name used must be already properly quoted. The command generated
|
|
|
|
* depends on the server version involved and it is semicolon-terminated.
|
2015-01-23 19:02:45 +01:00
|
|
|
*/
|
|
|
|
static void
|
Use catalog query to discover tables to process in vacuumdb
vacuumdb would use a catalog query only when the command caller does not
define a list of tables. Switching to a catalog table represents two
advantages:
- Relation existence check can happen before running any VACUUM or
ANALYZE query. Before this change, if multiple relations are defined
using --table, the utility would fail only after processing the
firstly-defined ones, which may be a long some depending on the size of
the relation. This adds checks for the relation names, and does
nothing, at least yet, for the attribute names.
- More filtering options can become available for the utility user.
These options, which may be introduced later on, are based on the
relation size or the relation age, and need to be made available even if
the user does not list any specific table with --table.
Author: Nathan Bossart
Reviewed-by: Michael Paquier, Masahiko Sawada
Discussion: https://postgr.es/m/FFE5373C-E26A-495B-B5C8-911EC4A41C5E@amazon.com
2019-01-29 03:22:03 +01:00
|
|
|
prepare_vacuum_command(PQExpBuffer sql, int serverVersion,
|
|
|
|
vacuumingOptions *vacopts, const char *table)
|
2015-01-23 19:02:45 +01:00
|
|
|
{
|
2019-01-08 02:52:29 +01:00
|
|
|
const char *paren = " (";
|
|
|
|
const char *comma = ", ";
|
|
|
|
const char *sep = paren;
|
|
|
|
|
2015-01-23 19:02:45 +01:00
|
|
|
resetPQExpBuffer(sql);
|
|
|
|
|
|
|
|
if (vacopts->analyze_only)
|
2010-01-06 06:31:14 +01:00
|
|
|
{
|
2015-01-23 19:02:45 +01:00
|
|
|
appendPQExpBufferStr(sql, "ANALYZE");
|
2019-01-08 02:52:29 +01:00
|
|
|
|
|
|
|
/* parenthesized grammar of ANALYZE is supported since v11 */
|
Use catalog query to discover tables to process in vacuumdb
vacuumdb would use a catalog query only when the command caller does not
define a list of tables. Switching to a catalog table represents two
advantages:
- Relation existence check can happen before running any VACUUM or
ANALYZE query. Before this change, if multiple relations are defined
using --table, the utility would fail only after processing the
firstly-defined ones, which may be a long some depending on the size of
the relation. This adds checks for the relation names, and does
nothing, at least yet, for the attribute names.
- More filtering options can become available for the utility user.
These options, which may be introduced later on, are based on the
relation size or the relation age, and need to be made available even if
the user does not list any specific table with --table.
Author: Nathan Bossart
Reviewed-by: Michael Paquier, Masahiko Sawada
Discussion: https://postgr.es/m/FFE5373C-E26A-495B-B5C8-911EC4A41C5E@amazon.com
2019-01-29 03:22:03 +01:00
|
|
|
if (serverVersion >= 110000)
|
2019-01-08 02:52:29 +01:00
|
|
|
{
|
|
|
|
if (vacopts->skip_locked)
|
|
|
|
{
|
|
|
|
/* SKIP_LOCKED is supported since v12 */
|
Use catalog query to discover tables to process in vacuumdb
vacuumdb would use a catalog query only when the command caller does not
define a list of tables. Switching to a catalog table represents two
advantages:
- Relation existence check can happen before running any VACUUM or
ANALYZE query. Before this change, if multiple relations are defined
using --table, the utility would fail only after processing the
firstly-defined ones, which may be a long some depending on the size of
the relation. This adds checks for the relation names, and does
nothing, at least yet, for the attribute names.
- More filtering options can become available for the utility user.
These options, which may be introduced later on, are based on the
relation size or the relation age, and need to be made available even if
the user does not list any specific table with --table.
Author: Nathan Bossart
Reviewed-by: Michael Paquier, Masahiko Sawada
Discussion: https://postgr.es/m/FFE5373C-E26A-495B-B5C8-911EC4A41C5E@amazon.com
2019-01-29 03:22:03 +01:00
|
|
|
Assert(serverVersion >= 120000);
|
2019-01-08 02:52:29 +01:00
|
|
|
appendPQExpBuffer(sql, "%sSKIP_LOCKED", sep);
|
|
|
|
sep = comma;
|
|
|
|
}
|
|
|
|
if (vacopts->verbose)
|
|
|
|
{
|
|
|
|
appendPQExpBuffer(sql, "%sVERBOSE", sep);
|
|
|
|
sep = comma;
|
|
|
|
}
|
|
|
|
if (sep != paren)
|
|
|
|
appendPQExpBufferChar(sql, ')');
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
if (vacopts->verbose)
|
|
|
|
appendPQExpBufferStr(sql, " VERBOSE");
|
|
|
|
}
|
2010-01-06 06:31:14 +01:00
|
|
|
}
|
2010-01-06 03:59:46 +01:00
|
|
|
else
|
|
|
|
{
|
2015-01-23 19:02:45 +01:00
|
|
|
appendPQExpBufferStr(sql, "VACUUM");
|
2019-01-08 02:52:29 +01:00
|
|
|
|
|
|
|
/* parenthesized grammar of VACUUM is supported since v9.0 */
|
Use catalog query to discover tables to process in vacuumdb
vacuumdb would use a catalog query only when the command caller does not
define a list of tables. Switching to a catalog table represents two
advantages:
- Relation existence check can happen before running any VACUUM or
ANALYZE query. Before this change, if multiple relations are defined
using --table, the utility would fail only after processing the
firstly-defined ones, which may be a long some depending on the size of
the relation. This adds checks for the relation names, and does
nothing, at least yet, for the attribute names.
- More filtering options can become available for the utility user.
These options, which may be introduced later on, are based on the
relation size or the relation age, and need to be made available even if
the user does not list any specific table with --table.
Author: Nathan Bossart
Reviewed-by: Michael Paquier, Masahiko Sawada
Discussion: https://postgr.es/m/FFE5373C-E26A-495B-B5C8-911EC4A41C5E@amazon.com
2019-01-29 03:22:03 +01:00
|
|
|
if (serverVersion >= 90000)
|
2010-01-06 06:31:14 +01:00
|
|
|
{
|
2019-01-08 02:52:29 +01:00
|
|
|
if (vacopts->disable_page_skipping)
|
|
|
|
{
|
|
|
|
/* DISABLE_PAGE_SKIPPING is supported since v9.6 */
|
Use catalog query to discover tables to process in vacuumdb
vacuumdb would use a catalog query only when the command caller does not
define a list of tables. Switching to a catalog table represents two
advantages:
- Relation existence check can happen before running any VACUUM or
ANALYZE query. Before this change, if multiple relations are defined
using --table, the utility would fail only after processing the
firstly-defined ones, which may be a long some depending on the size of
the relation. This adds checks for the relation names, and does
nothing, at least yet, for the attribute names.
- More filtering options can become available for the utility user.
These options, which may be introduced later on, are based on the
relation size or the relation age, and need to be made available even if
the user does not list any specific table with --table.
Author: Nathan Bossart
Reviewed-by: Michael Paquier, Masahiko Sawada
Discussion: https://postgr.es/m/FFE5373C-E26A-495B-B5C8-911EC4A41C5E@amazon.com
2019-01-29 03:22:03 +01:00
|
|
|
Assert(serverVersion >= 90600);
|
2019-01-08 02:52:29 +01:00
|
|
|
appendPQExpBuffer(sql, "%sDISABLE_PAGE_SKIPPING", sep);
|
|
|
|
sep = comma;
|
|
|
|
}
|
|
|
|
if (vacopts->skip_locked)
|
|
|
|
{
|
|
|
|
/* SKIP_LOCKED is supported since v12 */
|
Use catalog query to discover tables to process in vacuumdb
vacuumdb would use a catalog query only when the command caller does not
define a list of tables. Switching to a catalog table represents two
advantages:
- Relation existence check can happen before running any VACUUM or
ANALYZE query. Before this change, if multiple relations are defined
using --table, the utility would fail only after processing the
firstly-defined ones, which may be a long some depending on the size of
the relation. This adds checks for the relation names, and does
nothing, at least yet, for the attribute names.
- More filtering options can become available for the utility user.
These options, which may be introduced later on, are based on the
relation size or the relation age, and need to be made available even if
the user does not list any specific table with --table.
Author: Nathan Bossart
Reviewed-by: Michael Paquier, Masahiko Sawada
Discussion: https://postgr.es/m/FFE5373C-E26A-495B-B5C8-911EC4A41C5E@amazon.com
2019-01-29 03:22:03 +01:00
|
|
|
Assert(serverVersion >= 120000);
|
2019-01-08 02:52:29 +01:00
|
|
|
appendPQExpBuffer(sql, "%sSKIP_LOCKED", sep);
|
|
|
|
sep = comma;
|
|
|
|
}
|
2015-01-23 19:02:45 +01:00
|
|
|
if (vacopts->full)
|
2010-01-06 06:31:14 +01:00
|
|
|
{
|
2015-01-23 19:02:45 +01:00
|
|
|
appendPQExpBuffer(sql, "%sFULL", sep);
|
2010-01-06 06:31:14 +01:00
|
|
|
sep = comma;
|
|
|
|
}
|
2015-01-23 19:02:45 +01:00
|
|
|
if (vacopts->freeze)
|
2010-01-06 06:31:14 +01:00
|
|
|
{
|
2015-01-23 19:02:45 +01:00
|
|
|
appendPQExpBuffer(sql, "%sFREEZE", sep);
|
2010-01-06 06:31:14 +01:00
|
|
|
sep = comma;
|
|
|
|
}
|
2015-01-23 19:02:45 +01:00
|
|
|
if (vacopts->verbose)
|
2010-01-06 06:31:14 +01:00
|
|
|
{
|
2015-01-23 19:02:45 +01:00
|
|
|
appendPQExpBuffer(sql, "%sVERBOSE", sep);
|
2010-01-06 06:31:14 +01:00
|
|
|
sep = comma;
|
|
|
|
}
|
2015-01-23 19:02:45 +01:00
|
|
|
if (vacopts->and_analyze)
|
2010-01-06 06:31:14 +01:00
|
|
|
{
|
2015-01-23 19:02:45 +01:00
|
|
|
appendPQExpBuffer(sql, "%sANALYZE", sep);
|
2010-01-06 06:31:14 +01:00
|
|
|
sep = comma;
|
|
|
|
}
|
2020-01-29 06:38:50 +01:00
|
|
|
if (vacopts->parallel_workers >= 0)
|
|
|
|
{
|
|
|
|
/* PARALLEL is supported since v13 */
|
|
|
|
Assert(serverVersion >= 130000);
|
|
|
|
appendPQExpBuffer(sql, "%sPARALLEL %d", sep,
|
|
|
|
vacopts->parallel_workers);
|
|
|
|
sep = comma;
|
|
|
|
}
|
2010-01-06 06:31:14 +01:00
|
|
|
if (sep != paren)
|
2015-07-02 11:32:48 +02:00
|
|
|
appendPQExpBufferChar(sql, ')');
|
2010-01-06 06:31:14 +01:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2015-01-23 19:02:45 +01:00
|
|
|
if (vacopts->full)
|
|
|
|
appendPQExpBufferStr(sql, " FULL");
|
|
|
|
if (vacopts->freeze)
|
|
|
|
appendPQExpBufferStr(sql, " FREEZE");
|
|
|
|
if (vacopts->verbose)
|
|
|
|
appendPQExpBufferStr(sql, " VERBOSE");
|
|
|
|
if (vacopts->and_analyze)
|
|
|
|
appendPQExpBufferStr(sql, " ANALYZE");
|
2010-01-06 06:31:14 +01:00
|
|
|
}
|
2010-01-06 03:59:46 +01:00
|
|
|
}
|
2015-01-23 19:02:45 +01:00
|
|
|
|
Use catalog query to discover tables to process in vacuumdb
vacuumdb would use a catalog query only when the command caller does not
define a list of tables. Switching to a catalog table represents two
advantages:
- Relation existence check can happen before running any VACUUM or
ANALYZE query. Before this change, if multiple relations are defined
using --table, the utility would fail only after processing the
firstly-defined ones, which may be a long some depending on the size of
the relation. This adds checks for the relation names, and does
nothing, at least yet, for the attribute names.
- More filtering options can become available for the utility user.
These options, which may be introduced later on, are based on the
relation size or the relation age, and need to be made available even if
the user does not list any specific table with --table.
Author: Nathan Bossart
Reviewed-by: Michael Paquier, Masahiko Sawada
Discussion: https://postgr.es/m/FFE5373C-E26A-495B-B5C8-911EC4A41C5E@amazon.com
2019-01-29 03:22:03 +01:00
|
|
|
appendPQExpBuffer(sql, " %s;", table);
|
2015-01-23 19:02:45 +01:00
|
|
|
}
|
2003-06-18 14:19:11 +02:00
|
|
|
|
2015-01-23 19:02:45 +01:00
|
|
|
/*
|
2019-07-19 02:31:58 +02:00
|
|
|
* Send a vacuum/analyze command to the server, returning after sending the
|
|
|
|
* command.
|
2015-01-23 19:02:45 +01:00
|
|
|
*
|
2019-07-19 02:31:58 +02:00
|
|
|
* Any errors during command execution are reported to stderr.
|
2015-01-23 19:02:45 +01:00
|
|
|
*/
|
|
|
|
static void
|
|
|
|
run_vacuum_command(PGconn *conn, const char *sql, bool echo,
|
2019-07-23 07:29:34 +02:00
|
|
|
const char *table)
|
2015-01-23 19:02:45 +01:00
|
|
|
{
|
2015-05-24 03:35:49 +02:00
|
|
|
bool status;
|
2015-03-23 19:57:11 +01:00
|
|
|
|
2019-07-19 02:31:58 +02:00
|
|
|
if (echo)
|
|
|
|
printf("%s\n", sql);
|
2015-01-23 19:02:45 +01:00
|
|
|
|
2019-07-19 02:31:58 +02:00
|
|
|
status = PQsendQuery(conn, sql) == 1;
|
2015-03-23 19:57:11 +01:00
|
|
|
|
|
|
|
if (!status)
|
2015-01-23 19:02:45 +01:00
|
|
|
{
|
|
|
|
if (table)
|
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("vacuuming of table \"%s\" in database \"%s\" failed: %s",
|
|
|
|
table, PQdb(conn), PQerrorMessage(conn));
|
2015-01-23 19:02:45 +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("vacuuming of database \"%s\" failed: %s",
|
|
|
|
PQdb(conn), PQerrorMessage(conn));
|
2015-01-23 19:02:45 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2003-06-18 14:19:11 +02:00
|
|
|
static void
|
|
|
|
help(const char *progname)
|
|
|
|
{
|
|
|
|
printf(_("%s cleans and analyzes a PostgreSQL database.\n\n"), progname);
|
|
|
|
printf(_("Usage:\n"));
|
|
|
|
printf(_(" %s [OPTION]... [DBNAME]\n"), progname);
|
|
|
|
printf(_("\nOptions:\n"));
|
|
|
|
printf(_(" -a, --all vacuum all databases\n"));
|
|
|
|
printf(_(" -d, --dbname=DBNAME database to vacuum\n"));
|
2019-01-08 02:52:29 +01:00
|
|
|
printf(_(" --disable-page-skipping disable all page-skipping behavior\n"));
|
2009-02-25 14:03:07 +01:00
|
|
|
printf(_(" -e, --echo show the commands being sent to the server\n"));
|
2003-06-18 14:19:11 +02:00
|
|
|
printf(_(" -f, --full do full vacuuming\n"));
|
2009-02-18 13:11:55 +01:00
|
|
|
printf(_(" -F, --freeze freeze row transaction information\n"));
|
2015-09-16 06:37:39 +02:00
|
|
|
printf(_(" -j, --jobs=NUM use this many concurrent connections to vacuum\n"));
|
2019-01-31 05:06:51 +01:00
|
|
|
printf(_(" --min-mxid-age=MXID_AGE minimum multixact ID age of tables to vacuum\n"));
|
|
|
|
printf(_(" --min-xid-age=XID_AGE minimum transaction ID age of tables to vacuum\n"));
|
2020-01-29 06:38:50 +01:00
|
|
|
printf(_(" -P, --parallel=PARALLEL_DEGREE use this many background workers for vacuum, if available\n"));
|
2003-06-18 14:19:11 +02:00
|
|
|
printf(_(" -q, --quiet don't write any messages\n"));
|
2019-01-08 02:52:29 +01:00
|
|
|
printf(_(" --skip-locked skip relations that cannot be immediately locked\n"));
|
2013-01-17 11:24:47 +01:00
|
|
|
printf(_(" -t, --table='TABLE[(COLUMNS)]' vacuum specific table(s) only\n"));
|
2003-06-18 14:19:11 +02:00
|
|
|
printf(_(" -v, --verbose write a lot of output\n"));
|
2012-06-18 01:44:00 +02:00
|
|
|
printf(_(" -V, --version output version information, then exit\n"));
|
2010-02-26 05:14:36 +01:00
|
|
|
printf(_(" -z, --analyze update optimizer statistics\n"));
|
2015-09-16 06:37:39 +02:00
|
|
|
printf(_(" -Z, --analyze-only only update optimizer statistics; no vacuum\n"));
|
2014-04-15 05:15:05 +02:00
|
|
|
printf(_(" --analyze-in-stages only update optimizer statistics, in multiple\n"
|
2015-09-16 06:37:39 +02:00
|
|
|
" stages for faster results; no vacuum\n"));
|
2012-06-18 01:44:00 +02:00
|
|
|
printf(_(" -?, --help show this help, then exit\n"));
|
2003-06-18 14:19:11 +02:00
|
|
|
printf(_("\nConnection options:\n"));
|
|
|
|
printf(_(" -h, --host=HOSTNAME database server host or socket directory\n"));
|
|
|
|
printf(_(" -p, --port=PORT database server port\n"));
|
|
|
|
printf(_(" -U, --username=USERNAME user name to connect as\n"));
|
2009-02-26 17:02:39 +01:00
|
|
|
printf(_(" -w, --no-password never prompt for password\n"));
|
2007-12-11 20:57:32 +01:00
|
|
|
printf(_(" -W, --password force password prompt\n"));
|
2011-12-06 14:48:15 +01:00
|
|
|
printf(_(" --maintenance-db=DBNAME alternate maintenance database\n"));
|
2003-06-18 14:19:11 +02:00
|
|
|
printf(_("\nRead the description of the SQL command VACUUM for details.\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);
|
2003-06-18 14:19:11 +02:00
|
|
|
}
|