|
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
|
*
|
|
|
|
|
* vacuumdb
|
|
|
|
|
*
|
|
|
|
|
* Portions Copyright (c) 1996-2023, PostgreSQL Global Development Group
|
|
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
|
|
|
|
*
|
|
|
|
|
* src/bin/scripts/vacuumdb.c
|
|
|
|
|
*
|
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include "postgres_fe.h"
|
|
|
|
|
|
|
|
|
|
#include <limits.h>
|
|
|
|
|
|
|
|
|
|
#include "catalog/pg_class_d.h"
|
|
|
|
|
#include "common.h"
|
|
|
|
|
#include "common/connect.h"
|
|
|
|
|
#include "common/logging.h"
|
|
|
|
|
#include "fe_utils/cancel.h"
|
Move some code from src/bin/scripts to src/fe_utils to permit reuse.
The parallel slots infrastructure (which implements client-side
multiplexing of server connections doing similar things, not
threading or multiple processes or anything like that) are moved from
src/bin/scripts/scripts_parallel.c to src/fe_utils/parallel_slot.c.
The functions consumeQueryResult() and processQueryResult() which were
previously part of src/bin/scripts/common.c are now moved into that
file as well, becoming static helper functions. This might need to be
changed in the future, but currently they're not used for anything
else.
Some other functions from src/bin/scripts/common.c are moved to to
src/fe_utils and are split up among several files. connectDatabase(),
connectMaintenanceDatabase(), and disconnectDatabase() are moved to
connect_utils.c. executeQuery(), executeCommand(), and
executeMaintenanceCommand() are move to query_utils.c.
handle_help_version_opts() is moved to option_utils.c.
Mark Dilger, reviewed by me. The larger patch series of which this is
a part has also had review from Peter Geoghegan, Andres Freund, Álvaro
Herrera, Michael Paquier, and Amul Sul, but I don't know whether any
of them have reviewed this bit specifically.
Discussion: http://postgr.es/m/12ED3DA8-25F0-4B68-937D-D907CFBF08E7@enterprisedb.com
Discussion: http://postgr.es/m/5F743835-3399-419C-8324-2D424237E999@enterprisedb.com
Discussion: http://postgr.es/m/70655DF3-33CE-4527-9A4D-DDEB582B6BA0@enterprisedb.com
5 years ago
|
|
|
#include "fe_utils/option_utils.h"
|
|
|
|
|
#include "fe_utils/parallel_slot.h"
|
|
|
|
|
#include "fe_utils/query_utils.h"
|
|
|
|
|
#include "fe_utils/simple_list.h"
|
|
|
|
|
#include "fe_utils/string_utils.h"
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/* vacuum options controlled by user flags */
|
|
|
|
|
typedef struct vacuumingOptions
|
|
|
|
|
{
|
|
|
|
|
bool analyze_only;
|
|
|
|
|
bool verbose;
|
|
|
|
|
bool and_analyze;
|
|
|
|
|
bool full;
|
|
|
|
|
bool freeze;
|
|
|
|
|
bool disable_page_skipping;
|
|
|
|
|
bool skip_locked;
|
|
|
|
|
int min_xid_age;
|
|
|
|
|
int min_mxid_age;
|
|
|
|
|
int parallel_workers; /* >= 0 indicates user specified the
|
|
|
|
|
* parallel degree, otherwise -1 */
|
|
|
|
|
bool no_index_cleanup;
|
|
|
|
|
bool force_index_cleanup;
|
|
|
|
|
bool do_truncate;
|
|
|
|
|
bool process_main;
|
|
|
|
|
bool process_toast;
|
|
|
|
|
bool skip_database_stats;
|
|
|
|
|
char *buffer_usage_limit;
|
|
|
|
|
} vacuumingOptions;
|
|
|
|
|
|
|
|
|
|
/* object filter options */
|
|
|
|
|
typedef enum
|
|
|
|
|
{
|
|
|
|
|
OBJFILTER_NONE = 0, /* no filter used */
|
|
|
|
|
OBJFILTER_ALL_DBS = (1 << 0), /* -a | --all */
|
|
|
|
|
OBJFILTER_DATABASE = (1 << 1), /* -d | --dbname */
|
|
|
|
|
OBJFILTER_TABLE = (1 << 2), /* -t | --table */
|
|
|
|
|
OBJFILTER_SCHEMA = (1 << 3), /* -n | --schema */
|
|
|
|
|
OBJFILTER_SCHEMA_EXCLUDE = (1 << 4), /* -N | --exclude-schema */
|
|
|
|
|
} VacObjFilter;
|
|
|
|
|
|
|
|
|
|
VacObjFilter objfilter = OBJFILTER_NONE;
|
|
|
|
|
|
Refactor and generalize the ParallelSlot machinery.
Create a wrapper object, ParallelSlotArray, to encapsulate the
number of slots and the slot array itself, plus some other relevant
bits of information. This reduces the number of parameters we have
to pass around all over the place.
Allow for a ParallelSlotArray to contain slots connected to
different databases within a single cluster. The current clients
of this mechanism don't need this, but it is expected to be used
by future patches.
Defer connecting to databases until we actually need the connection
for something. This is a slight behavior change for vacuumdb and
reindexdb. If you specify a number of jobs that is larger than the
number of objects, the extra connections will now not be used.
But, on the other hand, if you specify a number of jobs that is
so large that it's going to fail, the failure would previously have
happened before any operations were actually started, and now it
won't.
Mark Dilger, reviewed by me.
Discussion: http://postgr.es/m/12ED3DA8-25F0-4B68-937D-D907CFBF08E7@enterprisedb.com
Discussion: http://postgr.es/m/BA592F2D-F928-46FF-9516-2B827F067F57@enterprisedb.com
5 years ago
|
|
|
static void vacuum_one_database(ConnParams *cparams,
|
Fix connection string handling in src/bin/scripts/ programs.
When told to process all databases, clusterdb, reindexdb, and vacuumdb
would reconnect by replacing their --maintenance-db parameter with the
name of the target database. If that parameter is a connstring (which
has been allowed for a long time, though we failed to document that
before this patch), we'd lose any other options it might specify, for
example SSL or GSS parameters, possibly resulting in failure to connect.
Thus, this is the same bug as commit a45bc8a4f fixed in pg_dump and
pg_restore. We can fix it in the same way, by using libpq's rules for
handling multiple "dbname" parameters to add the target database name
separately. I chose to apply the same refactoring approach as in that
patch, with a struct to handle the command line parameters that need to
be passed through to connectDatabase. (Maybe someday we can unify the
very similar functions here and in pg_dump/pg_restore.)
Per Peter Eisentraut's comments on bug #16604. Back-patch to all
supported branches.
Discussion: https://postgr.es/m/16604-933f4b8791227b15@postgresql.org
5 years ago
|
|
|
vacuumingOptions *vacopts,
|
|
|
|
|
int stage,
|
|
|
|
|
SimpleStringList *objects,
|
|
|
|
|
int concurrentCons,
|
|
|
|
|
const char *progname, bool echo, bool quiet);
|
|
|
|
|
|
Fix connection string handling in src/bin/scripts/ programs.
When told to process all databases, clusterdb, reindexdb, and vacuumdb
would reconnect by replacing their --maintenance-db parameter with the
name of the target database. If that parameter is a connstring (which
has been allowed for a long time, though we failed to document that
before this patch), we'd lose any other options it might specify, for
example SSL or GSS parameters, possibly resulting in failure to connect.
Thus, this is the same bug as commit a45bc8a4f fixed in pg_dump and
pg_restore. We can fix it in the same way, by using libpq's rules for
handling multiple "dbname" parameters to add the target database name
separately. I chose to apply the same refactoring approach as in that
patch, with a struct to handle the command line parameters that need to
be passed through to connectDatabase. (Maybe someday we can unify the
very similar functions here and in pg_dump/pg_restore.)
Per Peter Eisentraut's comments on bug #16604. Back-patch to all
supported branches.
Discussion: https://postgr.es/m/16604-933f4b8791227b15@postgresql.org
5 years ago
|
|
|
static void vacuum_all_databases(ConnParams *cparams,
|
|
|
|
|
vacuumingOptions *vacopts,
|
|
|
|
|
bool analyze_in_stages,
|
|
|
|
|
int concurrentCons,
|
|
|
|
|
const char *progname, bool echo, bool quiet);
|
|
|
|
|
|
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
7 years ago
|
|
|
static void prepare_vacuum_command(PQExpBuffer sql, int serverVersion,
|
|
|
|
|
vacuumingOptions *vacopts, const char *table);
|
|
|
|
|
|
|
|
|
|
static void run_vacuum_command(PGconn *conn, const char *sql, bool echo,
|
|
|
|
|
const char *table);
|
|
|
|
|
|
|
|
|
|
static void help(const char *progname);
|
|
|
|
|
|
|
|
|
|
void check_objfilter(void);
|
|
|
|
|
|
|
|
|
|
static char *escape_quotes(const char *src);
|
|
|
|
|
|
|
|
|
|
/* For analyze-in-stages mode */
|
|
|
|
|
#define ANALYZE_NO_STAGE -1
|
|
|
|
|
#define ANALYZE_NUM_STAGES 3
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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'},
|
|
|
|
|
{"no-password", no_argument, NULL, 'w'},
|
|
|
|
|
{"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'},
|
|
|
|
|
{"analyze-only", no_argument, NULL, 'Z'},
|
|
|
|
|
{"freeze", no_argument, NULL, 'F'},
|
|
|
|
|
{"all", no_argument, NULL, 'a'},
|
|
|
|
|
{"table", required_argument, NULL, 't'},
|
|
|
|
|
{"full", no_argument, NULL, 'f'},
|
|
|
|
|
{"verbose", no_argument, NULL, 'v'},
|
|
|
|
|
{"jobs", required_argument, NULL, 'j'},
|
|
|
|
|
{"parallel", required_argument, NULL, 'P'},
|
|
|
|
|
{"schema", required_argument, NULL, 'n'},
|
|
|
|
|
{"exclude-schema", required_argument, NULL, 'N'},
|
|
|
|
|
{"maintenance-db", required_argument, NULL, 2},
|
|
|
|
|
{"analyze-in-stages", no_argument, NULL, 3},
|
|
|
|
|
{"disable-page-skipping", no_argument, NULL, 4},
|
|
|
|
|
{"skip-locked", no_argument, NULL, 5},
|
|
|
|
|
{"min-xid-age", required_argument, NULL, 6},
|
|
|
|
|
{"min-mxid-age", required_argument, NULL, 7},
|
|
|
|
|
{"no-index-cleanup", no_argument, NULL, 8},
|
|
|
|
|
{"force-index-cleanup", no_argument, NULL, 9},
|
|
|
|
|
{"no-truncate", no_argument, NULL, 10},
|
|
|
|
|
{"no-process-toast", no_argument, NULL, 11},
|
|
|
|
|
{"no-process-main", no_argument, NULL, 12},
|
|
|
|
|
{"buffer-usage-limit", required_argument, NULL, 13},
|
|
|
|
|
{NULL, 0, NULL, 0}
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
const char *progname;
|
|
|
|
|
int optindex;
|
|
|
|
|
int c;
|
|
|
|
|
const char *dbname = NULL;
|
|
|
|
|
const char *maintenance_db = NULL;
|
|
|
|
|
char *host = NULL;
|
|
|
|
|
char *port = NULL;
|
|
|
|
|
char *username = NULL;
|
|
|
|
|
enum trivalue prompt_password = TRI_DEFAULT;
|
Fix connection string handling in src/bin/scripts/ programs.
When told to process all databases, clusterdb, reindexdb, and vacuumdb
would reconnect by replacing their --maintenance-db parameter with the
name of the target database. If that parameter is a connstring (which
has been allowed for a long time, though we failed to document that
before this patch), we'd lose any other options it might specify, for
example SSL or GSS parameters, possibly resulting in failure to connect.
Thus, this is the same bug as commit a45bc8a4f fixed in pg_dump and
pg_restore. We can fix it in the same way, by using libpq's rules for
handling multiple "dbname" parameters to add the target database name
separately. I chose to apply the same refactoring approach as in that
patch, with a struct to handle the command line parameters that need to
be passed through to connectDatabase. (Maybe someday we can unify the
very similar functions here and in pg_dump/pg_restore.)
Per Peter Eisentraut's comments on bug #16604. Back-patch to all
supported branches.
Discussion: https://postgr.es/m/16604-933f4b8791227b15@postgresql.org
5 years ago
|
|
|
ConnParams cparams;
|
|
|
|
|
bool echo = false;
|
|
|
|
|
bool quiet = false;
|
|
|
|
|
vacuumingOptions vacopts;
|
|
|
|
|
bool analyze_in_stages = false;
|
|
|
|
|
SimpleStringList objects = {NULL, NULL};
|
|
|
|
|
int concurrentCons = 1;
|
|
|
|
|
int tbl_count = 0;
|
|
|
|
|
|
|
|
|
|
/* initialize options */
|
|
|
|
|
memset(&vacopts, 0, sizeof(vacopts));
|
|
|
|
|
vacopts.parallel_workers = -1;
|
|
|
|
|
vacopts.buffer_usage_limit = NULL;
|
|
|
|
|
vacopts.no_index_cleanup = false;
|
|
|
|
|
vacopts.force_index_cleanup = false;
|
|
|
|
|
vacopts.do_truncate = true;
|
|
|
|
|
vacopts.process_main = true;
|
|
|
|
|
vacopts.process_toast = true;
|
|
|
|
|
|
Unified logging system for command-line programs
This unifies the various ad hoc logging (message printing, error
printing) systems used throughout the command-line programs.
Features:
- Program name is automatically prefixed.
- Message string does not end with newline. This removes a common
source of inconsistencies and omissions.
- Additionally, a final newline is automatically stripped, simplifying
use of PQerrorMessage() etc., another common source of mistakes.
- I converted error message strings to use %m where possible.
- As a result of the above several points, more translatable message
strings can be shared between different components and between
frontends and backend, without gratuitous punctuation or whitespace
differences.
- There is support for setting a "log level". This is not meant to be
user-facing, but can be used internally to implement debug or
verbose modes.
- Lazy argument evaluation, so no significant overhead if logging at
some level is disabled.
- Some color in the messages, similar to gcc and clang. Set
PG_COLOR=auto to try it out. Some colors are predefined, but can be
customized by setting PG_COLORS.
- Common files (common/, fe_utils/, etc.) can handle logging much more
simply by just using one API without worrying too much about the
context of the calling program, requiring callbacks, or having to
pass "progname" around everywhere.
- Some programs called setvbuf() to make sure that stderr is
unbuffered, even on Windows. But not all programs did that. This
is now done centrally.
Soft goals:
- Reduces vertical space use and visual complexity of error reporting
in the source code.
- Encourages more deliberate classification of messages. For example,
in some cases it wasn't clear without analyzing the surrounding code
whether a message was meant as an error or just an info.
- Concepts and terms are vaguely aligned with popular logging
frameworks such as log4j and Python logging.
This is all just about printing stuff out. Nothing affects program
flow (e.g., fatal exits). The uses are just too varied to do that.
Some existing code had wrappers that do some kind of print-and-exit,
and I adapted those.
I tried to keep the output mostly the same, but there is a lot of
historical baggage to unwind and special cases to consider, and I
might not always have succeeded. One significant change is that
pg_rewind used to write all error messages to stdout. That is now
changed to stderr.
Reviewed-by: Donald Dong <xdong@csumb.edu>
Reviewed-by: Arthur Zakirov <a.zakirov@postgrespro.ru>
Discussion: https://www.postgresql.org/message-id/flat/6a609b43-4f57-7348-6480-bd022f924310@2ndquadrant.com
7 years ago
|
|
|
pg_logging_init(argv[0]);
|
|
|
|
|
progname = get_progname(argv[0]);
|
|
|
|
|
set_pglocale_pgservice(argv[0], PG_TEXTDOMAIN("pgscripts"));
|
|
|
|
|
|
|
|
|
|
handle_help_version_opts(argc, argv, "vacuumdb", help);
|
|
|
|
|
|
|
|
|
|
while ((c = getopt_long(argc, argv, "ad:efFh:j:n:N:p:P:qt:U:vwWzZ", long_options, &optindex)) != -1)
|
|
|
|
|
{
|
|
|
|
|
switch (c)
|
|
|
|
|
{
|
|
|
|
|
case 'a':
|
|
|
|
|
objfilter |= OBJFILTER_ALL_DBS;
|
|
|
|
|
break;
|
|
|
|
|
case 'd':
|
|
|
|
|
objfilter |= OBJFILTER_DATABASE;
|
|
|
|
|
dbname = pg_strdup(optarg);
|
|
|
|
|
break;
|
|
|
|
|
case 'e':
|
|
|
|
|
echo = true;
|
|
|
|
|
break;
|
|
|
|
|
case 'f':
|
|
|
|
|
vacopts.full = true;
|
|
|
|
|
break;
|
|
|
|
|
case 'F':
|
|
|
|
|
vacopts.freeze = true;
|
|
|
|
|
break;
|
|
|
|
|
case 'h':
|
|
|
|
|
host = pg_strdup(optarg);
|
|
|
|
|
break;
|
|
|
|
|
case 'j':
|
|
|
|
|
if (!option_parse_int(optarg, "-j/--jobs", 1, INT_MAX,
|
|
|
|
|
&concurrentCons))
|
|
|
|
|
exit(1);
|
|
|
|
|
break;
|
|
|
|
|
case 'n':
|
|
|
|
|
objfilter |= OBJFILTER_SCHEMA;
|
|
|
|
|
simple_string_list_append(&objects, optarg);
|
|
|
|
|
break;
|
|
|
|
|
case 'N':
|
|
|
|
|
objfilter |= OBJFILTER_SCHEMA_EXCLUDE;
|
|
|
|
|
simple_string_list_append(&objects, optarg);
|
|
|
|
|
break;
|
|
|
|
|
case 'p':
|
|
|
|
|
port = pg_strdup(optarg);
|
|
|
|
|
break;
|
|
|
|
|
case 'P':
|
|
|
|
|
if (!option_parse_int(optarg, "-P/--parallel", 0, INT_MAX,
|
|
|
|
|
&vacopts.parallel_workers))
|
|
|
|
|
exit(1);
|
|
|
|
|
break;
|
|
|
|
|
case 'q':
|
|
|
|
|
quiet = true;
|
|
|
|
|
break;
|
|
|
|
|
case 't':
|
|
|
|
|
objfilter |= OBJFILTER_TABLE;
|
|
|
|
|
simple_string_list_append(&objects, optarg);
|
|
|
|
|
tbl_count++;
|
|
|
|
|
break;
|
|
|
|
|
case 'U':
|
|
|
|
|
username = pg_strdup(optarg);
|
|
|
|
|
break;
|
|
|
|
|
case 'v':
|
|
|
|
|
vacopts.verbose = true;
|
|
|
|
|
break;
|
|
|
|
|
case 'w':
|
|
|
|
|
prompt_password = TRI_NO;
|
|
|
|
|
break;
|
|
|
|
|
case 'W':
|
|
|
|
|
prompt_password = TRI_YES;
|
|
|
|
|
break;
|
|
|
|
|
case 'z':
|
|
|
|
|
vacopts.and_analyze = true;
|
|
|
|
|
break;
|
|
|
|
|
case 'Z':
|
|
|
|
|
vacopts.analyze_only = true;
|
|
|
|
|
break;
|
|
|
|
|
case 2:
|
|
|
|
|
maintenance_db = pg_strdup(optarg);
|
|
|
|
|
break;
|
|
|
|
|
case 3:
|
|
|
|
|
analyze_in_stages = vacopts.analyze_only = true;
|
|
|
|
|
break;
|
|
|
|
|
case 4:
|
|
|
|
|
vacopts.disable_page_skipping = true;
|
|
|
|
|
break;
|
|
|
|
|
case 5:
|
|
|
|
|
vacopts.skip_locked = true;
|
|
|
|
|
break;
|
|
|
|
|
case 6:
|
|
|
|
|
if (!option_parse_int(optarg, "--min-xid-age", 1, INT_MAX,
|
|
|
|
|
&vacopts.min_xid_age))
|
|
|
|
|
exit(1);
|
|
|
|
|
break;
|
|
|
|
|
case 7:
|
|
|
|
|
if (!option_parse_int(optarg, "--min-mxid-age", 1, INT_MAX,
|
|
|
|
|
&vacopts.min_mxid_age))
|
|
|
|
|
exit(1);
|
|
|
|
|
break;
|
|
|
|
|
case 8:
|
|
|
|
|
vacopts.no_index_cleanup = true;
|
|
|
|
|
break;
|
|
|
|
|
case 9:
|
|
|
|
|
vacopts.force_index_cleanup = true;
|
|
|
|
|
break;
|
|
|
|
|
case 10:
|
|
|
|
|
vacopts.do_truncate = false;
|
|
|
|
|
break;
|
|
|
|
|
case 11:
|
|
|
|
|
vacopts.process_toast = false;
|
|
|
|
|
break;
|
|
|
|
|
case 12:
|
|
|
|
|
vacopts.process_main = false;
|
|
|
|
|
break;
|
|
|
|
|
case 13:
|
|
|
|
|
vacopts.buffer_usage_limit = escape_quotes(optarg);
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
/* getopt_long already emitted a complaint */
|
|
|
|
|
pg_log_error_hint("Try \"%s --help\" for more information.", progname);
|
|
|
|
|
exit(1);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Non-option argument specifies database name as long as it wasn't
|
|
|
|
|
* already specified with -d / --dbname
|
|
|
|
|
*/
|
|
|
|
|
if (optind < argc && dbname == NULL)
|
|
|
|
|
{
|
|
|
|
|
objfilter |= OBJFILTER_DATABASE;
|
|
|
|
|
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
7 years ago
|
|
|
pg_log_error("too many command-line arguments (first is \"%s\")",
|
|
|
|
|
argv[optind]);
|
|
|
|
|
pg_log_error_hint("Try \"%s --help\" for more information.", progname);
|
|
|
|
|
exit(1);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Validate the combination of filters specified in the command-line
|
|
|
|
|
* options.
|
|
|
|
|
*/
|
|
|
|
|
check_objfilter();
|
|
|
|
|
|
|
|
|
|
if (vacopts.analyze_only)
|
|
|
|
|
{
|
|
|
|
|
if (vacopts.full)
|
|
|
|
|
pg_fatal("cannot use the \"%s\" option when performing only analyze",
|
|
|
|
|
"full");
|
|
|
|
|
if (vacopts.freeze)
|
|
|
|
|
pg_fatal("cannot use the \"%s\" option when performing only analyze",
|
|
|
|
|
"freeze");
|
|
|
|
|
if (vacopts.disable_page_skipping)
|
|
|
|
|
pg_fatal("cannot use the \"%s\" option when performing only analyze",
|
|
|
|
|
"disable-page-skipping");
|
|
|
|
|
if (vacopts.no_index_cleanup)
|
|
|
|
|
pg_fatal("cannot use the \"%s\" option when performing only analyze",
|
|
|
|
|
"no-index-cleanup");
|
|
|
|
|
if (vacopts.force_index_cleanup)
|
|
|
|
|
pg_fatal("cannot use the \"%s\" option when performing only analyze",
|
|
|
|
|
"force-index-cleanup");
|
|
|
|
|
if (!vacopts.do_truncate)
|
|
|
|
|
pg_fatal("cannot use the \"%s\" option when performing only analyze",
|
|
|
|
|
"no-truncate");
|
|
|
|
|
if (!vacopts.process_main)
|
|
|
|
|
pg_fatal("cannot use the \"%s\" option when performing only analyze",
|
|
|
|
|
"no-process-main");
|
|
|
|
|
if (!vacopts.process_toast)
|
|
|
|
|
pg_fatal("cannot use the \"%s\" option when performing only analyze",
|
|
|
|
|
"no-process-toast");
|
|
|
|
|
/* allow 'and_analyze' with 'analyze_only' */
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Prohibit full and analyze_only options with parallel option */
|
|
|
|
|
if (vacopts.parallel_workers >= 0)
|
|
|
|
|
{
|
|
|
|
|
if (vacopts.analyze_only)
|
|
|
|
|
pg_fatal("cannot use the \"%s\" option when performing only analyze",
|
|
|
|
|
"parallel");
|
|
|
|
|
if (vacopts.full)
|
|
|
|
|
pg_fatal("cannot use the \"%s\" option when performing full vacuum",
|
|
|
|
|
"parallel");
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Prohibit --no-index-cleanup and --force-index-cleanup together */
|
|
|
|
|
if (vacopts.no_index_cleanup && vacopts.force_index_cleanup)
|
|
|
|
|
pg_fatal("cannot use the \"%s\" option with the \"%s\" option",
|
|
|
|
|
"no-index-cleanup", "force-index-cleanup");
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* buffer-usage-limit is not allowed with VACUUM FULL unless ANALYZE is
|
|
|
|
|
* included too.
|
|
|
|
|
*/
|
|
|
|
|
if (vacopts.buffer_usage_limit && vacopts.full && !vacopts.and_analyze)
|
|
|
|
|
pg_fatal("cannot use the \"%s\" option with the \"%s\" option",
|
|
|
|
|
"buffer-usage-limit", "full");
|
|
|
|
|
|
Fix connection string handling in src/bin/scripts/ programs.
When told to process all databases, clusterdb, reindexdb, and vacuumdb
would reconnect by replacing their --maintenance-db parameter with the
name of the target database. If that parameter is a connstring (which
has been allowed for a long time, though we failed to document that
before this patch), we'd lose any other options it might specify, for
example SSL or GSS parameters, possibly resulting in failure to connect.
Thus, this is the same bug as commit a45bc8a4f fixed in pg_dump and
pg_restore. We can fix it in the same way, by using libpq's rules for
handling multiple "dbname" parameters to add the target database name
separately. I chose to apply the same refactoring approach as in that
patch, with a struct to handle the command line parameters that need to
be passed through to connectDatabase. (Maybe someday we can unify the
very similar functions here and in pg_dump/pg_restore.)
Per Peter Eisentraut's comments on bug #16604. Back-patch to all
supported branches.
Discussion: https://postgr.es/m/16604-933f4b8791227b15@postgresql.org
5 years ago
|
|
|
/* fill cparams except for dbname, which is set below */
|
|
|
|
|
cparams.pghost = host;
|
|
|
|
|
cparams.pgport = port;
|
|
|
|
|
cparams.pguser = username;
|
|
|
|
|
cparams.prompt_password = prompt_password;
|
|
|
|
|
cparams.override_dbname = NULL;
|
|
|
|
|
|
|
|
|
|
setup_cancel_handler(NULL);
|
|
|
|
|
|
|
|
|
|
/* Avoid opening extra connections. */
|
|
|
|
|
if (tbl_count && (concurrentCons > tbl_count))
|
|
|
|
|
concurrentCons = tbl_count;
|
|
|
|
|
|
|
|
|
|
if (objfilter & OBJFILTER_ALL_DBS)
|
|
|
|
|
{
|
Fix connection string handling in src/bin/scripts/ programs.
When told to process all databases, clusterdb, reindexdb, and vacuumdb
would reconnect by replacing their --maintenance-db parameter with the
name of the target database. If that parameter is a connstring (which
has been allowed for a long time, though we failed to document that
before this patch), we'd lose any other options it might specify, for
example SSL or GSS parameters, possibly resulting in failure to connect.
Thus, this is the same bug as commit a45bc8a4f fixed in pg_dump and
pg_restore. We can fix it in the same way, by using libpq's rules for
handling multiple "dbname" parameters to add the target database name
separately. I chose to apply the same refactoring approach as in that
patch, with a struct to handle the command line parameters that need to
be passed through to connectDatabase. (Maybe someday we can unify the
very similar functions here and in pg_dump/pg_restore.)
Per Peter Eisentraut's comments on bug #16604. Back-patch to all
supported branches.
Discussion: https://postgr.es/m/16604-933f4b8791227b15@postgresql.org
5 years ago
|
|
|
cparams.dbname = maintenance_db;
|
|
|
|
|
|
|
|
|
|
vacuum_all_databases(&cparams, &vacopts,
|
|
|
|
|
analyze_in_stages,
|
|
|
|
|
concurrentCons,
|
|
|
|
|
progname, echo, quiet);
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
if (dbname == NULL)
|
|
|
|
|
{
|
|
|
|
|
if (getenv("PGDATABASE"))
|
|
|
|
|
dbname = getenv("PGDATABASE");
|
|
|
|
|
else if (getenv("PGUSER"))
|
|
|
|
|
dbname = getenv("PGUSER");
|
|
|
|
|
else
|
|
|
|
|
dbname = get_user_name_or_exit(progname);
|
|
|
|
|
}
|
|
|
|
|
|
Fix connection string handling in src/bin/scripts/ programs.
When told to process all databases, clusterdb, reindexdb, and vacuumdb
would reconnect by replacing their --maintenance-db parameter with the
name of the target database. If that parameter is a connstring (which
has been allowed for a long time, though we failed to document that
before this patch), we'd lose any other options it might specify, for
example SSL or GSS parameters, possibly resulting in failure to connect.
Thus, this is the same bug as commit a45bc8a4f fixed in pg_dump and
pg_restore. We can fix it in the same way, by using libpq's rules for
handling multiple "dbname" parameters to add the target database name
separately. I chose to apply the same refactoring approach as in that
patch, with a struct to handle the command line parameters that need to
be passed through to connectDatabase. (Maybe someday we can unify the
very similar functions here and in pg_dump/pg_restore.)
Per Peter Eisentraut's comments on bug #16604. Back-patch to all
supported branches.
Discussion: https://postgr.es/m/16604-933f4b8791227b15@postgresql.org
5 years ago
|
|
|
cparams.dbname = dbname;
|
|
|
|
|
|
|
|
|
|
if (analyze_in_stages)
|
|
|
|
|
{
|
|
|
|
|
int stage;
|
|
|
|
|
|
|
|
|
|
for (stage = 0; stage < ANALYZE_NUM_STAGES; stage++)
|
|
|
|
|
{
|
Fix connection string handling in src/bin/scripts/ programs.
When told to process all databases, clusterdb, reindexdb, and vacuumdb
would reconnect by replacing their --maintenance-db parameter with the
name of the target database. If that parameter is a connstring (which
has been allowed for a long time, though we failed to document that
before this patch), we'd lose any other options it might specify, for
example SSL or GSS parameters, possibly resulting in failure to connect.
Thus, this is the same bug as commit a45bc8a4f fixed in pg_dump and
pg_restore. We can fix it in the same way, by using libpq's rules for
handling multiple "dbname" parameters to add the target database name
separately. I chose to apply the same refactoring approach as in that
patch, with a struct to handle the command line parameters that need to
be passed through to connectDatabase. (Maybe someday we can unify the
very similar functions here and in pg_dump/pg_restore.)
Per Peter Eisentraut's comments on bug #16604. Back-patch to all
supported branches.
Discussion: https://postgr.es/m/16604-933f4b8791227b15@postgresql.org
5 years ago
|
|
|
vacuum_one_database(&cparams, &vacopts,
|
|
|
|
|
stage,
|
|
|
|
|
&objects,
|
|
|
|
|
concurrentCons,
|
|
|
|
|
progname, echo, quiet);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else
|
Fix connection string handling in src/bin/scripts/ programs.
When told to process all databases, clusterdb, reindexdb, and vacuumdb
would reconnect by replacing their --maintenance-db parameter with the
name of the target database. If that parameter is a connstring (which
has been allowed for a long time, though we failed to document that
before this patch), we'd lose any other options it might specify, for
example SSL or GSS parameters, possibly resulting in failure to connect.
Thus, this is the same bug as commit a45bc8a4f fixed in pg_dump and
pg_restore. We can fix it in the same way, by using libpq's rules for
handling multiple "dbname" parameters to add the target database name
separately. I chose to apply the same refactoring approach as in that
patch, with a struct to handle the command line parameters that need to
be passed through to connectDatabase. (Maybe someday we can unify the
very similar functions here and in pg_dump/pg_restore.)
Per Peter Eisentraut's comments on bug #16604. Back-patch to all
supported branches.
Discussion: https://postgr.es/m/16604-933f4b8791227b15@postgresql.org
5 years ago
|
|
|
vacuum_one_database(&cparams, &vacopts,
|
|
|
|
|
ANALYZE_NO_STAGE,
|
|
|
|
|
&objects,
|
|
|
|
|
concurrentCons,
|
|
|
|
|
progname, echo, quiet);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
exit(0);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Verify that the filters used at command line are compatible.
|
|
|
|
|
*/
|
|
|
|
|
void
|
|
|
|
|
check_objfilter(void)
|
|
|
|
|
{
|
|
|
|
|
if ((objfilter & OBJFILTER_ALL_DBS) &&
|
|
|
|
|
(objfilter & OBJFILTER_DATABASE))
|
|
|
|
|
pg_fatal("cannot vacuum all databases and a specific one at the same time");
|
|
|
|
|
|
|
|
|
|
if ((objfilter & OBJFILTER_ALL_DBS) &&
|
|
|
|
|
(objfilter & OBJFILTER_TABLE))
|
|
|
|
|
pg_fatal("cannot vacuum specific table(s) in all databases");
|
|
|
|
|
|
|
|
|
|
if ((objfilter & OBJFILTER_ALL_DBS) &&
|
|
|
|
|
(objfilter & OBJFILTER_SCHEMA))
|
|
|
|
|
pg_fatal("cannot vacuum specific schema(s) in all databases");
|
|
|
|
|
|
|
|
|
|
if ((objfilter & OBJFILTER_ALL_DBS) &&
|
|
|
|
|
(objfilter & OBJFILTER_SCHEMA_EXCLUDE))
|
|
|
|
|
pg_fatal("cannot exclude specific schema(s) in all databases");
|
|
|
|
|
|
|
|
|
|
if ((objfilter & OBJFILTER_TABLE) &&
|
|
|
|
|
(objfilter & OBJFILTER_SCHEMA))
|
|
|
|
|
pg_fatal("cannot vacuum all tables in schema(s) and specific table(s) at the same time");
|
|
|
|
|
|
|
|
|
|
if ((objfilter & OBJFILTER_TABLE) &&
|
|
|
|
|
(objfilter & OBJFILTER_SCHEMA_EXCLUDE))
|
|
|
|
|
pg_fatal("cannot vacuum specific table(s) and exclude schema(s) at the same time");
|
|
|
|
|
|
|
|
|
|
if ((objfilter & OBJFILTER_SCHEMA) &&
|
|
|
|
|
(objfilter & OBJFILTER_SCHEMA_EXCLUDE))
|
|
|
|
|
pg_fatal("cannot vacuum all tables in schema(s) and exclude schema(s) at the same time");
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Returns a newly malloc'd version of 'src' with escaped single quotes and
|
|
|
|
|
* backslashes.
|
|
|
|
|
*/
|
|
|
|
|
static char *
|
|
|
|
|
escape_quotes(const char *src)
|
|
|
|
|
{
|
|
|
|
|
char *result = escape_single_quotes_ascii(src);
|
|
|
|
|
|
|
|
|
|
if (!result)
|
|
|
|
|
pg_fatal("out of memory");
|
|
|
|
|
return result;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* 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.
|
|
|
|
|
*/
|
|
|
|
|
static void
|
Refactor and generalize the ParallelSlot machinery.
Create a wrapper object, ParallelSlotArray, to encapsulate the
number of slots and the slot array itself, plus some other relevant
bits of information. This reduces the number of parameters we have
to pass around all over the place.
Allow for a ParallelSlotArray to contain slots connected to
different databases within a single cluster. The current clients
of this mechanism don't need this, but it is expected to be used
by future patches.
Defer connecting to databases until we actually need the connection
for something. This is a slight behavior change for vacuumdb and
reindexdb. If you specify a number of jobs that is larger than the
number of objects, the extra connections will now not be used.
But, on the other hand, if you specify a number of jobs that is
so large that it's going to fail, the failure would previously have
happened before any operations were actually started, and now it
won't.
Mark Dilger, reviewed by me.
Discussion: http://postgr.es/m/12ED3DA8-25F0-4B68-937D-D907CFBF08E7@enterprisedb.com
Discussion: http://postgr.es/m/BA592F2D-F928-46FF-9516-2B827F067F57@enterprisedb.com
5 years ago
|
|
|
vacuum_one_database(ConnParams *cparams,
|
Fix connection string handling in src/bin/scripts/ programs.
When told to process all databases, clusterdb, reindexdb, and vacuumdb
would reconnect by replacing their --maintenance-db parameter with the
name of the target database. If that parameter is a connstring (which
has been allowed for a long time, though we failed to document that
before this patch), we'd lose any other options it might specify, for
example SSL or GSS parameters, possibly resulting in failure to connect.
Thus, this is the same bug as commit a45bc8a4f fixed in pg_dump and
pg_restore. We can fix it in the same way, by using libpq's rules for
handling multiple "dbname" parameters to add the target database name
separately. I chose to apply the same refactoring approach as in that
patch, with a struct to handle the command line parameters that need to
be passed through to connectDatabase. (Maybe someday we can unify the
very similar functions here and in pg_dump/pg_restore.)
Per Peter Eisentraut's comments on bug #16604. Back-patch to all
supported branches.
Discussion: https://postgr.es/m/16604-933f4b8791227b15@postgresql.org
5 years ago
|
|
|
vacuumingOptions *vacopts,
|
|
|
|
|
int stage,
|
|
|
|
|
SimpleStringList *objects,
|
|
|
|
|
int concurrentCons,
|
|
|
|
|
const char *progname, bool echo, bool quiet)
|
|
|
|
|
{
|
|
|
|
|
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
7 years ago
|
|
|
PQExpBufferData buf;
|
|
|
|
|
PQExpBufferData catalog_query;
|
|
|
|
|
PGresult *res;
|
|
|
|
|
PGconn *conn;
|
|
|
|
|
SimpleStringListCell *cell;
|
Refactor and generalize the ParallelSlot machinery.
Create a wrapper object, ParallelSlotArray, to encapsulate the
number of slots and the slot array itself, plus some other relevant
bits of information. This reduces the number of parameters we have
to pass around all over the place.
Allow for a ParallelSlotArray to contain slots connected to
different databases within a single cluster. The current clients
of this mechanism don't need this, but it is expected to be used
by future patches.
Defer connecting to databases until we actually need the connection
for something. This is a slight behavior change for vacuumdb and
reindexdb. If you specify a number of jobs that is larger than the
number of objects, the extra connections will now not be used.
But, on the other hand, if you specify a number of jobs that is
so large that it's going to fail, the failure would previously have
happened before any operations were actually started, and now it
won't.
Mark Dilger, reviewed by me.
Discussion: http://postgr.es/m/12ED3DA8-25F0-4B68-937D-D907CFBF08E7@enterprisedb.com
Discussion: http://postgr.es/m/BA592F2D-F928-46FF-9516-2B827F067F57@enterprisedb.com
5 years ago
|
|
|
ParallelSlotArray *sa;
|
|
|
|
|
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
7 years ago
|
|
|
int ntups;
|
|
|
|
|
bool failed = false;
|
|
|
|
|
bool objects_listed = false;
|
|
|
|
|
bool has_where = false;
|
Refactor and generalize the ParallelSlot machinery.
Create a wrapper object, ParallelSlotArray, to encapsulate the
number of slots and the slot array itself, plus some other relevant
bits of information. This reduces the number of parameters we have
to pass around all over the place.
Allow for a ParallelSlotArray to contain slots connected to
different databases within a single cluster. The current clients
of this mechanism don't need this, but it is expected to be used
by future patches.
Defer connecting to databases until we actually need the connection
for something. This is a slight behavior change for vacuumdb and
reindexdb. If you specify a number of jobs that is larger than the
number of objects, the extra connections will now not be used.
But, on the other hand, if you specify a number of jobs that is
so large that it's going to fail, the failure would previously have
happened before any operations were actually started, and now it
won't.
Mark Dilger, reviewed by me.
Discussion: http://postgr.es/m/12ED3DA8-25F0-4B68-937D-D907CFBF08E7@enterprisedb.com
Discussion: http://postgr.es/m/BA592F2D-F928-46FF-9516-2B827F067F57@enterprisedb.com
5 years ago
|
|
|
const char *initcmd;
|
|
|
|
|
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));
|
|
|
|
|
|
Fix connection string handling in src/bin/scripts/ programs.
When told to process all databases, clusterdb, reindexdb, and vacuumdb
would reconnect by replacing their --maintenance-db parameter with the
name of the target database. If that parameter is a connstring (which
has been allowed for a long time, though we failed to document that
before this patch), we'd lose any other options it might specify, for
example SSL or GSS parameters, possibly resulting in failure to connect.
Thus, this is the same bug as commit a45bc8a4f fixed in pg_dump and
pg_restore. We can fix it in the same way, by using libpq's rules for
handling multiple "dbname" parameters to add the target database name
separately. I chose to apply the same refactoring approach as in that
patch, with a struct to handle the command line parameters that need to
be passed through to connectDatabase. (Maybe someday we can unify the
very similar functions here and in pg_dump/pg_restore.)
Per Peter Eisentraut's comments on bug #16604. Back-patch to all
supported branches.
Discussion: https://postgr.es/m/16604-933f4b8791227b15@postgresql.org
5 years ago
|
|
|
conn = connectDatabase(cparams, progname, echo, false, true);
|
|
|
|
|
|
|
|
|
|
if (vacopts->disable_page_skipping && PQserverVersion(conn) < 90600)
|
|
|
|
|
{
|
|
|
|
|
PQfinish(conn);
|
|
|
|
|
pg_fatal("cannot use the \"%s\" option on server versions older than PostgreSQL %s",
|
|
|
|
|
"disable-page-skipping", "9.6");
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (vacopts->no_index_cleanup && PQserverVersion(conn) < 120000)
|
|
|
|
|
{
|
|
|
|
|
PQfinish(conn);
|
|
|
|
|
pg_fatal("cannot use the \"%s\" option on server versions older than PostgreSQL %s",
|
|
|
|
|
"no-index-cleanup", "12");
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (vacopts->force_index_cleanup && PQserverVersion(conn) < 120000)
|
|
|
|
|
{
|
|
|
|
|
PQfinish(conn);
|
|
|
|
|
pg_fatal("cannot use the \"%s\" option on server versions older than PostgreSQL %s",
|
|
|
|
|
"force-index-cleanup", "12");
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (!vacopts->do_truncate && PQserverVersion(conn) < 120000)
|
|
|
|
|
{
|
|
|
|
|
PQfinish(conn);
|
|
|
|
|
pg_fatal("cannot use the \"%s\" option on server versions older than PostgreSQL %s",
|
|
|
|
|
"no-truncate", "12");
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (!vacopts->process_main && PQserverVersion(conn) < 160000)
|
|
|
|
|
{
|
|
|
|
|
PQfinish(conn);
|
|
|
|
|
pg_fatal("cannot use the \"%s\" option on server versions older than PostgreSQL %s",
|
|
|
|
|
"no-process-main", "16");
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (!vacopts->process_toast && PQserverVersion(conn) < 140000)
|
|
|
|
|
{
|
|
|
|
|
PQfinish(conn);
|
|
|
|
|
pg_fatal("cannot use the \"%s\" option on server versions older than PostgreSQL %s",
|
|
|
|
|
"no-process-toast", "14");
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (vacopts->skip_locked && PQserverVersion(conn) < 120000)
|
|
|
|
|
{
|
|
|
|
|
PQfinish(conn);
|
|
|
|
|
pg_fatal("cannot use the \"%s\" option on server versions older than PostgreSQL %s",
|
|
|
|
|
"skip-locked", "12");
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (vacopts->min_xid_age != 0 && PQserverVersion(conn) < 90600)
|
|
|
|
|
pg_fatal("cannot use the \"%s\" option on server versions older than PostgreSQL %s",
|
|
|
|
|
"--min-xid-age", "9.6");
|
|
|
|
|
|
|
|
|
|
if (vacopts->min_mxid_age != 0 && PQserverVersion(conn) < 90600)
|
|
|
|
|
pg_fatal("cannot use the \"%s\" option on server versions older than PostgreSQL %s",
|
|
|
|
|
"--min-mxid-age", "9.6");
|
|
|
|
|
|
|
|
|
|
if (vacopts->parallel_workers >= 0 && PQserverVersion(conn) < 130000)
|
|
|
|
|
pg_fatal("cannot use the \"%s\" option on server versions older than PostgreSQL %s",
|
|
|
|
|
"--parallel", "13");
|
|
|
|
|
|
|
|
|
|
if (vacopts->buffer_usage_limit && PQserverVersion(conn) < 160000)
|
|
|
|
|
pg_fatal("cannot use the \"%s\" option on server versions older than PostgreSQL %s",
|
|
|
|
|
"--buffer-usage-limit", "16");
|
|
|
|
|
|
|
|
|
|
/* skip_database_stats is used automatically if server supports it */
|
|
|
|
|
vacopts->skip_database_stats = (PQserverVersion(conn) >= 160000);
|
|
|
|
|
|
|
|
|
|
if (!quiet)
|
|
|
|
|
{
|
|
|
|
|
if (stage != ANALYZE_NO_STAGE)
|
|
|
|
|
printf(_("%s: processing database \"%s\": %s\n"),
|
|
|
|
|
progname, PQdb(conn), _(stage_messages[stage]));
|
|
|
|
|
else
|
|
|
|
|
printf(_("%s: vacuuming database \"%s\"\n"),
|
|
|
|
|
progname, PQdb(conn));
|
|
|
|
|
fflush(stdout);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
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
7 years ago
|
|
|
* 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.
|
|
|
|
|
*/
|
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
7 years ago
|
|
|
initPQExpBuffer(&catalog_query);
|
|
|
|
|
for (cell = objects ? objects->head : NULL; cell; cell = cell->next)
|
|
|
|
|
{
|
|
|
|
|
char *just_table = NULL;
|
|
|
|
|
const char *just_columns = NULL;
|
|
|
|
|
|
|
|
|
|
if (!objects_listed)
|
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
7 years ago
|
|
|
{
|
|
|
|
|
appendPQExpBufferStr(&catalog_query,
|
|
|
|
|
"WITH listed_objects (object_oid, column_list) "
|
|
|
|
|
"AS (\n VALUES (");
|
|
|
|
|
objects_listed = 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
7 years ago
|
|
|
else
|
|
|
|
|
appendPQExpBufferStr(&catalog_query, ",\n (");
|
|
|
|
|
|
|
|
|
|
if (objfilter & (OBJFILTER_SCHEMA | OBJFILTER_SCHEMA_EXCLUDE))
|
|
|
|
|
{
|
|
|
|
|
appendStringLiteralConn(&catalog_query, cell->val, conn);
|
|
|
|
|
appendPQExpBufferStr(&catalog_query, "::pg_catalog.regnamespace, ");
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (objfilter & OBJFILTER_TABLE)
|
|
|
|
|
{
|
|
|
|
|
/*
|
|
|
|
|
* 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);
|
|
|
|
|
|
|
|
|
|
appendStringLiteralConn(&catalog_query, just_table, conn);
|
|
|
|
|
appendPQExpBufferStr(&catalog_query, "::pg_catalog.regclass, ");
|
|
|
|
|
}
|
|
|
|
|
|
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
7 years ago
|
|
|
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 (objects_listed)
|
|
|
|
|
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
7 years ago
|
|
|
|
|
|
|
|
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
7 years ago
|
|
|
|
|
|
|
|
if (objects_listed)
|
|
|
|
|
appendPQExpBufferStr(&catalog_query, ", listed_objects.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
7 years ago
|
|
|
|
|
|
|
|
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
7 years ago
|
|
|
|
|
|
|
|
/* Used to match the tables or schemas listed by the user */
|
|
|
|
|
if (objects_listed)
|
|
|
|
|
{
|
|
|
|
|
appendPQExpBufferStr(&catalog_query, " LEFT JOIN listed_objects"
|
|
|
|
|
" ON listed_objects.object_oid"
|
|
|
|
|
" OPERATOR(pg_catalog.=) ");
|
|
|
|
|
|
|
|
|
|
if (objfilter & OBJFILTER_TABLE)
|
|
|
|
|
appendPQExpBufferStr(&catalog_query, "c.oid\n");
|
|
|
|
|
else
|
|
|
|
|
appendPQExpBufferStr(&catalog_query, "ns.oid\n");
|
|
|
|
|
|
|
|
|
|
if (objfilter & OBJFILTER_SCHEMA_EXCLUDE)
|
|
|
|
|
appendPQExpBuffer(&catalog_query,
|
|
|
|
|
" WHERE listed_objects.object_oid IS NULL\n");
|
|
|
|
|
else
|
|
|
|
|
appendPQExpBuffer(&catalog_query,
|
|
|
|
|
" WHERE listed_objects.object_oid IS NOT NULL\n");
|
|
|
|
|
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
7 years ago
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* 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 ((objfilter & OBJFILTER_TABLE) == 0)
|
|
|
|
|
{
|
|
|
|
|
appendPQExpBuffer(&catalog_query,
|
|
|
|
|
" %s c.relkind OPERATOR(pg_catalog.=) ANY (array["
|
|
|
|
|
CppAsString2(RELKIND_RELATION) ", "
|
|
|
|
|
CppAsString2(RELKIND_MATVIEW) "])\n",
|
|
|
|
|
has_where ? "AND" : "WHERE");
|
|
|
|
|
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
7 years ago
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Execute the catalog query. We use the default search_path for this
|
|
|
|
|
* query for consistency with table lookups done elsewhere by the user.
|
|
|
|
|
*/
|
|
|
|
|
appendPQExpBufferStr(&catalog_query, " ORDER BY c.relpages DESC;");
|
|
|
|
|
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
7 years ago
|
|
|
termPQExpBuffer(&catalog_query);
|
|
|
|
|
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
7 years ago
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* 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 (objects_listed && !PQgetisnull(res, i, 2))
|
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
7 years ago
|
|
|
appendPQExpBufferStr(&buf, PQgetvalue(res, i, 2));
|
|
|
|
|
|
|
|
|
|
simple_string_list_append(&dbtables, buf.data);
|
|
|
|
|
resetPQExpBuffer(&buf);
|
|
|
|
|
}
|
|
|
|
|
termPQExpBuffer(&buf);
|
|
|
|
|
PQclear(res);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Ensure concurrentCons is sane. If there are more connections than
|
|
|
|
|
* vacuumable relations, we don't need to use them all.
|
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
7 years ago
|
|
|
*/
|
|
|
|
|
if (concurrentCons > ntups)
|
|
|
|
|
concurrentCons = ntups;
|
|
|
|
|
if (concurrentCons <= 0)
|
|
|
|
|
concurrentCons = 1;
|
|
|
|
|
|
|
|
|
|
/*
|
Refactor and generalize the ParallelSlot machinery.
Create a wrapper object, ParallelSlotArray, to encapsulate the
number of slots and the slot array itself, plus some other relevant
bits of information. This reduces the number of parameters we have
to pass around all over the place.
Allow for a ParallelSlotArray to contain slots connected to
different databases within a single cluster. The current clients
of this mechanism don't need this, but it is expected to be used
by future patches.
Defer connecting to databases until we actually need the connection
for something. This is a slight behavior change for vacuumdb and
reindexdb. If you specify a number of jobs that is larger than the
number of objects, the extra connections will now not be used.
But, on the other hand, if you specify a number of jobs that is
so large that it's going to fail, the failure would previously have
happened before any operations were actually started, and now it
won't.
Mark Dilger, reviewed by me.
Discussion: http://postgr.es/m/12ED3DA8-25F0-4B68-937D-D907CFBF08E7@enterprisedb.com
Discussion: http://postgr.es/m/BA592F2D-F928-46FF-9516-2B827F067F57@enterprisedb.com
5 years ago
|
|
|
* All slots need to be prepared to run the appropriate analyze stage, if
|
|
|
|
|
* caller requested that mode. We have to prepare the initial connection
|
|
|
|
|
* ourselves before setting up the slots.
|
|
|
|
|
*/
|
Refactor and generalize the ParallelSlot machinery.
Create a wrapper object, ParallelSlotArray, to encapsulate the
number of slots and the slot array itself, plus some other relevant
bits of information. This reduces the number of parameters we have
to pass around all over the place.
Allow for a ParallelSlotArray to contain slots connected to
different databases within a single cluster. The current clients
of this mechanism don't need this, but it is expected to be used
by future patches.
Defer connecting to databases until we actually need the connection
for something. This is a slight behavior change for vacuumdb and
reindexdb. If you specify a number of jobs that is larger than the
number of objects, the extra connections will now not be used.
But, on the other hand, if you specify a number of jobs that is
so large that it's going to fail, the failure would previously have
happened before any operations were actually started, and now it
won't.
Mark Dilger, reviewed by me.
Discussion: http://postgr.es/m/12ED3DA8-25F0-4B68-937D-D907CFBF08E7@enterprisedb.com
Discussion: http://postgr.es/m/BA592F2D-F928-46FF-9516-2B827F067F57@enterprisedb.com
5 years ago
|
|
|
if (stage == ANALYZE_NO_STAGE)
|
|
|
|
|
initcmd = NULL;
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
initcmd = stage_commands[stage];
|
|
|
|
|
executeCommand(conn, initcmd, echo);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
Refactor and generalize the ParallelSlot machinery.
Create a wrapper object, ParallelSlotArray, to encapsulate the
number of slots and the slot array itself, plus some other relevant
bits of information. This reduces the number of parameters we have
to pass around all over the place.
Allow for a ParallelSlotArray to contain slots connected to
different databases within a single cluster. The current clients
of this mechanism don't need this, but it is expected to be used
by future patches.
Defer connecting to databases until we actually need the connection
for something. This is a slight behavior change for vacuumdb and
reindexdb. If you specify a number of jobs that is larger than the
number of objects, the extra connections will now not be used.
But, on the other hand, if you specify a number of jobs that is
so large that it's going to fail, the failure would previously have
happened before any operations were actually started, and now it
won't.
Mark Dilger, reviewed by me.
Discussion: http://postgr.es/m/12ED3DA8-25F0-4B68-937D-D907CFBF08E7@enterprisedb.com
Discussion: http://postgr.es/m/BA592F2D-F928-46FF-9516-2B827F067F57@enterprisedb.com
5 years ago
|
|
|
* 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.
|
|
|
|
|
*/
|
Refactor and generalize the ParallelSlot machinery.
Create a wrapper object, ParallelSlotArray, to encapsulate the
number of slots and the slot array itself, plus some other relevant
bits of information. This reduces the number of parameters we have
to pass around all over the place.
Allow for a ParallelSlotArray to contain slots connected to
different databases within a single cluster. The current clients
of this mechanism don't need this, but it is expected to be used
by future patches.
Defer connecting to databases until we actually need the connection
for something. This is a slight behavior change for vacuumdb and
reindexdb. If you specify a number of jobs that is larger than the
number of objects, the extra connections will now not be used.
But, on the other hand, if you specify a number of jobs that is
so large that it's going to fail, the failure would previously have
happened before any operations were actually started, and now it
won't.
Mark Dilger, reviewed by me.
Discussion: http://postgr.es/m/12ED3DA8-25F0-4B68-937D-D907CFBF08E7@enterprisedb.com
Discussion: http://postgr.es/m/BA592F2D-F928-46FF-9516-2B827F067F57@enterprisedb.com
5 years ago
|
|
|
sa = ParallelSlotsSetup(concurrentCons, cparams, progname, echo, initcmd);
|
|
|
|
|
ParallelSlotsAdoptConn(sa, conn);
|
|
|
|
|
|
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
7 years ago
|
|
|
initPQExpBuffer(&sql);
|
|
|
|
|
|
|
|
|
|
cell = dbtables.head;
|
|
|
|
|
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
7 years ago
|
|
|
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
8 years ago
|
|
|
ParallelSlot *free_slot;
|
|
|
|
|
|
|
|
|
|
if (CancelRequested)
|
|
|
|
|
{
|
|
|
|
|
failed = true;
|
|
|
|
|
goto finish;
|
|
|
|
|
}
|
|
|
|
|
|
Refactor and generalize the ParallelSlot machinery.
Create a wrapper object, ParallelSlotArray, to encapsulate the
number of slots and the slot array itself, plus some other relevant
bits of information. This reduces the number of parameters we have
to pass around all over the place.
Allow for a ParallelSlotArray to contain slots connected to
different databases within a single cluster. The current clients
of this mechanism don't need this, but it is expected to be used
by future patches.
Defer connecting to databases until we actually need the connection
for something. This is a slight behavior change for vacuumdb and
reindexdb. If you specify a number of jobs that is larger than the
number of objects, the extra connections will now not be used.
But, on the other hand, if you specify a number of jobs that is
so large that it's going to fail, the failure would previously have
happened before any operations were actually started, and now it
won't.
Mark Dilger, reviewed by me.
Discussion: http://postgr.es/m/12ED3DA8-25F0-4B68-937D-D907CFBF08E7@enterprisedb.com
Discussion: http://postgr.es/m/BA592F2D-F928-46FF-9516-2B827F067F57@enterprisedb.com
5 years ago
|
|
|
free_slot = ParallelSlotsGetIdle(sa, NULL);
|
|
|
|
|
if (!free_slot)
|
|
|
|
|
{
|
|
|
|
|
failed = true;
|
|
|
|
|
goto finish;
|
|
|
|
|
}
|
|
|
|
|
|
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
7 years ago
|
|
|
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
8 years ago
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Execute the vacuum. All errors are handled in processQueryResult
|
|
|
|
|
* through ParallelSlotsGetIdle.
|
|
|
|
|
*/
|
|
|
|
|
ParallelSlotSetHandler(free_slot, TableCommandResultHandler, NULL);
|
|
|
|
|
run_vacuum_command(free_slot->connection, sql.data,
|
|
|
|
|
echo, tabname);
|
|
|
|
|
|
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
7 years ago
|
|
|
cell = cell->next;
|
|
|
|
|
} while (cell != NULL);
|
|
|
|
|
|
Refactor and generalize the ParallelSlot machinery.
Create a wrapper object, ParallelSlotArray, to encapsulate the
number of slots and the slot array itself, plus some other relevant
bits of information. This reduces the number of parameters we have
to pass around all over the place.
Allow for a ParallelSlotArray to contain slots connected to
different databases within a single cluster. The current clients
of this mechanism don't need this, but it is expected to be used
by future patches.
Defer connecting to databases until we actually need the connection
for something. This is a slight behavior change for vacuumdb and
reindexdb. If you specify a number of jobs that is larger than the
number of objects, the extra connections will now not be used.
But, on the other hand, if you specify a number of jobs that is
so large that it's going to fail, the failure would previously have
happened before any operations were actually started, and now it
won't.
Mark Dilger, reviewed by me.
Discussion: http://postgr.es/m/12ED3DA8-25F0-4B68-937D-D907CFBF08E7@enterprisedb.com
Discussion: http://postgr.es/m/BA592F2D-F928-46FF-9516-2B827F067F57@enterprisedb.com
5 years ago
|
|
|
if (!ParallelSlotsWaitCompletion(sa))
|
|
|
|
|
{
|
|
|
|
|
failed = true;
|
|
|
|
|
goto finish;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* If we used SKIP_DATABASE_STATS, mop up with ONLY_DATABASE_STATS */
|
|
|
|
|
if (vacopts->skip_database_stats && stage == ANALYZE_NO_STAGE)
|
|
|
|
|
{
|
|
|
|
|
const char *cmd = "VACUUM (ONLY_DATABASE_STATS);";
|
|
|
|
|
ParallelSlot *free_slot = ParallelSlotsGetIdle(sa, NULL);
|
|
|
|
|
|
|
|
|
|
if (!free_slot)
|
|
|
|
|
{
|
|
|
|
|
failed = true;
|
|
|
|
|
goto finish;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ParallelSlotSetHandler(free_slot, TableCommandResultHandler, NULL);
|
|
|
|
|
run_vacuum_command(free_slot->connection, cmd, echo, NULL);
|
|
|
|
|
|
|
|
|
|
if (!ParallelSlotsWaitCompletion(sa))
|
|
|
|
|
failed = true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
finish:
|
Refactor and generalize the ParallelSlot machinery.
Create a wrapper object, ParallelSlotArray, to encapsulate the
number of slots and the slot array itself, plus some other relevant
bits of information. This reduces the number of parameters we have
to pass around all over the place.
Allow for a ParallelSlotArray to contain slots connected to
different databases within a single cluster. The current clients
of this mechanism don't need this, but it is expected to be used
by future patches.
Defer connecting to databases until we actually need the connection
for something. This is a slight behavior change for vacuumdb and
reindexdb. If you specify a number of jobs that is larger than the
number of objects, the extra connections will now not be used.
But, on the other hand, if you specify a number of jobs that is
so large that it's going to fail, the failure would previously have
happened before any operations were actually started, and now it
won't.
Mark Dilger, reviewed by me.
Discussion: http://postgr.es/m/12ED3DA8-25F0-4B68-937D-D907CFBF08E7@enterprisedb.com
Discussion: http://postgr.es/m/BA592F2D-F928-46FF-9516-2B827F067F57@enterprisedb.com
5 years ago
|
|
|
ParallelSlotsTerminate(sa);
|
|
|
|
|
pg_free(sa);
|
|
|
|
|
|
|
|
|
|
termPQExpBuffer(&sql);
|
|
|
|
|
|
|
|
|
|
if (failed)
|
|
|
|
|
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.
|
|
|
|
|
*/
|
|
|
|
|
static void
|
Fix connection string handling in src/bin/scripts/ programs.
When told to process all databases, clusterdb, reindexdb, and vacuumdb
would reconnect by replacing their --maintenance-db parameter with the
name of the target database. If that parameter is a connstring (which
has been allowed for a long time, though we failed to document that
before this patch), we'd lose any other options it might specify, for
example SSL or GSS parameters, possibly resulting in failure to connect.
Thus, this is the same bug as commit a45bc8a4f fixed in pg_dump and
pg_restore. We can fix it in the same way, by using libpq's rules for
handling multiple "dbname" parameters to add the target database name
separately. I chose to apply the same refactoring approach as in that
patch, with a struct to handle the command line parameters that need to
be passed through to connectDatabase. (Maybe someday we can unify the
very similar functions here and in pg_dump/pg_restore.)
Per Peter Eisentraut's comments on bug #16604. Back-patch to all
supported branches.
Discussion: https://postgr.es/m/16604-933f4b8791227b15@postgresql.org
5 years ago
|
|
|
vacuum_all_databases(ConnParams *cparams,
|
|
|
|
|
vacuumingOptions *vacopts,
|
|
|
|
|
bool analyze_in_stages,
|
|
|
|
|
int concurrentCons,
|
|
|
|
|
const char *progname, bool echo, bool quiet)
|
|
|
|
|
{
|
|
|
|
|
PGconn *conn;
|
|
|
|
|
PGresult *result;
|
|
|
|
|
int stage;
|
|
|
|
|
int i;
|
|
|
|
|
|
Fix connection string handling in src/bin/scripts/ programs.
When told to process all databases, clusterdb, reindexdb, and vacuumdb
would reconnect by replacing their --maintenance-db parameter with the
name of the target database. If that parameter is a connstring (which
has been allowed for a long time, though we failed to document that
before this patch), we'd lose any other options it might specify, for
example SSL or GSS parameters, possibly resulting in failure to connect.
Thus, this is the same bug as commit a45bc8a4f fixed in pg_dump and
pg_restore. We can fix it in the same way, by using libpq's rules for
handling multiple "dbname" parameters to add the target database name
separately. I chose to apply the same refactoring approach as in that
patch, with a struct to handle the command line parameters that need to
be passed through to connectDatabase. (Maybe someday we can unify the
very similar functions here and in pg_dump/pg_restore.)
Per Peter Eisentraut's comments on bug #16604. Back-patch to all
supported branches.
Discussion: https://postgr.es/m/16604-933f4b8791227b15@postgresql.org
5 years ago
|
|
|
conn = connectMaintenanceDatabase(cparams, progname, echo);
|
|
|
|
|
result = executeQuery(conn,
|
Handle DROP DATABASE getting interrupted
Until now, when DROP DATABASE got interrupted in the wrong moment, the removal
of the pg_database row would also roll back, even though some irreversible
steps have already been taken. E.g. DropDatabaseBuffers() might have thrown
out dirty buffers, or files could have been unlinked. But we continued to
allow connections to such a corrupted database.
To fix this, mark databases invalid with an in-place update, just before
starting to perform irreversible steps. As we can't add a new column in the
back branches, we use pg_database.datconnlimit = -2 for this purpose.
An invalid database cannot be connected to anymore, but can still be
dropped.
Unfortunately we can't easily add output to psql's \l to indicate that some
database is invalid, it doesn't fit in any of the existing columns.
Add tests verifying that a interrupted DROP DATABASE is handled correctly in
the backend and in various tools.
Reported-by: Evgeny Morozov <postgresql3@realityexists.net>
Author: Andres Freund <andres@anarazel.de>
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>
Reviewed-by: Thomas Munro <thomas.munro@gmail.com>
Discussion: https://postgr.es/m/20230509004637.cgvmfwrbht7xm7p6@awork3.anarazel.de
Discussion: https://postgr.es/m/20230314174521.74jl6ffqsee5mtug@awork3.anarazel.de
Backpatch: 11-, bug present in all supported versions
2 years ago
|
|
|
"SELECT datname FROM pg_database WHERE datallowconn AND datconnlimit <> -2 ORDER BY 1;",
|
|
|
|
|
echo);
|
|
|
|
|
PQfinish(conn);
|
|
|
|
|
|
|
|
|
|
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++)
|
|
|
|
|
{
|
Fix connection string handling in src/bin/scripts/ programs.
When told to process all databases, clusterdb, reindexdb, and vacuumdb
would reconnect by replacing their --maintenance-db parameter with the
name of the target database. If that parameter is a connstring (which
has been allowed for a long time, though we failed to document that
before this patch), we'd lose any other options it might specify, for
example SSL or GSS parameters, possibly resulting in failure to connect.
Thus, this is the same bug as commit a45bc8a4f fixed in pg_dump and
pg_restore. We can fix it in the same way, by using libpq's rules for
handling multiple "dbname" parameters to add the target database name
separately. I chose to apply the same refactoring approach as in that
patch, with a struct to handle the command line parameters that need to
be passed through to connectDatabase. (Maybe someday we can unify the
very similar functions here and in pg_dump/pg_restore.)
Per Peter Eisentraut's comments on bug #16604. Back-patch to all
supported branches.
Discussion: https://postgr.es/m/16604-933f4b8791227b15@postgresql.org
5 years ago
|
|
|
cparams->override_dbname = PQgetvalue(result, i, 0);
|
|
|
|
|
|
Fix connection string handling in src/bin/scripts/ programs.
When told to process all databases, clusterdb, reindexdb, and vacuumdb
would reconnect by replacing their --maintenance-db parameter with the
name of the target database. If that parameter is a connstring (which
has been allowed for a long time, though we failed to document that
before this patch), we'd lose any other options it might specify, for
example SSL or GSS parameters, possibly resulting in failure to connect.
Thus, this is the same bug as commit a45bc8a4f fixed in pg_dump and
pg_restore. We can fix it in the same way, by using libpq's rules for
handling multiple "dbname" parameters to add the target database name
separately. I chose to apply the same refactoring approach as in that
patch, with a struct to handle the command line parameters that need to
be passed through to connectDatabase. (Maybe someday we can unify the
very similar functions here and in pg_dump/pg_restore.)
Per Peter Eisentraut's comments on bug #16604. Back-patch to all
supported branches.
Discussion: https://postgr.es/m/16604-933f4b8791227b15@postgresql.org
5 years ago
|
|
|
vacuum_one_database(cparams, vacopts,
|
|
|
|
|
stage,
|
|
|
|
|
NULL,
|
|
|
|
|
concurrentCons,
|
|
|
|
|
progname, echo, quiet);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
for (i = 0; i < PQntuples(result); i++)
|
|
|
|
|
{
|
Fix connection string handling in src/bin/scripts/ programs.
When told to process all databases, clusterdb, reindexdb, and vacuumdb
would reconnect by replacing their --maintenance-db parameter with the
name of the target database. If that parameter is a connstring (which
has been allowed for a long time, though we failed to document that
before this patch), we'd lose any other options it might specify, for
example SSL or GSS parameters, possibly resulting in failure to connect.
Thus, this is the same bug as commit a45bc8a4f fixed in pg_dump and
pg_restore. We can fix it in the same way, by using libpq's rules for
handling multiple "dbname" parameters to add the target database name
separately. I chose to apply the same refactoring approach as in that
patch, with a struct to handle the command line parameters that need to
be passed through to connectDatabase. (Maybe someday we can unify the
very similar functions here and in pg_dump/pg_restore.)
Per Peter Eisentraut's comments on bug #16604. Back-patch to all
supported branches.
Discussion: https://postgr.es/m/16604-933f4b8791227b15@postgresql.org
5 years ago
|
|
|
cparams->override_dbname = PQgetvalue(result, i, 0);
|
|
|
|
|
|
Fix connection string handling in src/bin/scripts/ programs.
When told to process all databases, clusterdb, reindexdb, and vacuumdb
would reconnect by replacing their --maintenance-db parameter with the
name of the target database. If that parameter is a connstring (which
has been allowed for a long time, though we failed to document that
before this patch), we'd lose any other options it might specify, for
example SSL or GSS parameters, possibly resulting in failure to connect.
Thus, this is the same bug as commit a45bc8a4f fixed in pg_dump and
pg_restore. We can fix it in the same way, by using libpq's rules for
handling multiple "dbname" parameters to add the target database name
separately. I chose to apply the same refactoring approach as in that
patch, with a struct to handle the command line parameters that need to
be passed through to connectDatabase. (Maybe someday we can unify the
very similar functions here and in pg_dump/pg_restore.)
Per Peter Eisentraut's comments on bug #16604. Back-patch to all
supported branches.
Discussion: https://postgr.es/m/16604-933f4b8791227b15@postgresql.org
5 years ago
|
|
|
vacuum_one_database(cparams, vacopts,
|
|
|
|
|
ANALYZE_NO_STAGE,
|
|
|
|
|
NULL,
|
|
|
|
|
concurrentCons,
|
|
|
|
|
progname, echo, quiet);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
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
7 years ago
|
|
|
* The table name used must be already properly quoted. The command generated
|
|
|
|
|
* depends on the server version involved and it is semicolon-terminated.
|
|
|
|
|
*/
|
|
|
|
|
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
7 years ago
|
|
|
prepare_vacuum_command(PQExpBuffer sql, int serverVersion,
|
|
|
|
|
vacuumingOptions *vacopts, const char *table)
|
|
|
|
|
{
|
|
|
|
|
const char *paren = " (";
|
|
|
|
|
const char *comma = ", ";
|
|
|
|
|
const char *sep = paren;
|
|
|
|
|
|
|
|
|
|
resetPQExpBuffer(sql);
|
|
|
|
|
|
|
|
|
|
if (vacopts->analyze_only)
|
|
|
|
|
{
|
|
|
|
|
appendPQExpBufferStr(sql, "ANALYZE");
|
|
|
|
|
|
|
|
|
|
/* 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
7 years ago
|
|
|
if (serverVersion >= 110000)
|
|
|
|
|
{
|
|
|
|
|
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
7 years ago
|
|
|
Assert(serverVersion >= 120000);
|
|
|
|
|
appendPQExpBuffer(sql, "%sSKIP_LOCKED", sep);
|
|
|
|
|
sep = comma;
|
|
|
|
|
}
|
|
|
|
|
if (vacopts->verbose)
|
|
|
|
|
{
|
|
|
|
|
appendPQExpBuffer(sql, "%sVERBOSE", sep);
|
|
|
|
|
sep = comma;
|
|
|
|
|
}
|
|
|
|
|
if (vacopts->buffer_usage_limit)
|
|
|
|
|
{
|
|
|
|
|
Assert(serverVersion >= 160000);
|
|
|
|
|
appendPQExpBuffer(sql, "%sBUFFER_USAGE_LIMIT '%s'", sep,
|
|
|
|
|
vacopts->buffer_usage_limit);
|
|
|
|
|
sep = comma;
|
|
|
|
|
}
|
|
|
|
|
if (sep != paren)
|
|
|
|
|
appendPQExpBufferChar(sql, ')');
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
if (vacopts->verbose)
|
|
|
|
|
appendPQExpBufferStr(sql, " VERBOSE");
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
appendPQExpBufferStr(sql, "VACUUM");
|
|
|
|
|
|
|
|
|
|
/* 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
7 years ago
|
|
|
if (serverVersion >= 90000)
|
|
|
|
|
{
|
|
|
|
|
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
7 years ago
|
|
|
Assert(serverVersion >= 90600);
|
|
|
|
|
appendPQExpBuffer(sql, "%sDISABLE_PAGE_SKIPPING", sep);
|
|
|
|
|
sep = comma;
|
|
|
|
|
}
|
|
|
|
|
if (vacopts->no_index_cleanup)
|
|
|
|
|
{
|
|
|
|
|
/* "INDEX_CLEANUP FALSE" has been supported since v12 */
|
|
|
|
|
Assert(serverVersion >= 120000);
|
|
|
|
|
Assert(!vacopts->force_index_cleanup);
|
|
|
|
|
appendPQExpBuffer(sql, "%sINDEX_CLEANUP FALSE", sep);
|
|
|
|
|
sep = comma;
|
|
|
|
|
}
|
|
|
|
|
if (vacopts->force_index_cleanup)
|
|
|
|
|
{
|
|
|
|
|
/* "INDEX_CLEANUP TRUE" has been supported since v12 */
|
|
|
|
|
Assert(serverVersion >= 120000);
|
|
|
|
|
Assert(!vacopts->no_index_cleanup);
|
|
|
|
|
appendPQExpBuffer(sql, "%sINDEX_CLEANUP TRUE", sep);
|
|
|
|
|
sep = comma;
|
|
|
|
|
}
|
|
|
|
|
if (!vacopts->do_truncate)
|
|
|
|
|
{
|
|
|
|
|
/* TRUNCATE is supported since v12 */
|
|
|
|
|
Assert(serverVersion >= 120000);
|
|
|
|
|
appendPQExpBuffer(sql, "%sTRUNCATE FALSE", sep);
|
|
|
|
|
sep = comma;
|
|
|
|
|
}
|
|
|
|
|
if (!vacopts->process_main)
|
|
|
|
|
{
|
|
|
|
|
/* PROCESS_MAIN is supported since v16 */
|
|
|
|
|
Assert(serverVersion >= 160000);
|
|
|
|
|
appendPQExpBuffer(sql, "%sPROCESS_MAIN FALSE", sep);
|
|
|
|
|
sep = comma;
|
|
|
|
|
}
|
|
|
|
|
if (!vacopts->process_toast)
|
|
|
|
|
{
|
|
|
|
|
/* PROCESS_TOAST is supported since v14 */
|
|
|
|
|
Assert(serverVersion >= 140000);
|
|
|
|
|
appendPQExpBuffer(sql, "%sPROCESS_TOAST FALSE", sep);
|
|
|
|
|
sep = comma;
|
|
|
|
|
}
|
|
|
|
|
if (vacopts->skip_database_stats)
|
|
|
|
|
{
|
|
|
|
|
/* SKIP_DATABASE_STATS is supported since v16 */
|
|
|
|
|
Assert(serverVersion >= 160000);
|
|
|
|
|
appendPQExpBuffer(sql, "%sSKIP_DATABASE_STATS", 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
7 years ago
|
|
|
Assert(serverVersion >= 120000);
|
|
|
|
|
appendPQExpBuffer(sql, "%sSKIP_LOCKED", sep);
|
|
|
|
|
sep = comma;
|
|
|
|
|
}
|
|
|
|
|
if (vacopts->full)
|
|
|
|
|
{
|
|
|
|
|
appendPQExpBuffer(sql, "%sFULL", sep);
|
|
|
|
|
sep = comma;
|
|
|
|
|
}
|
|
|
|
|
if (vacopts->freeze)
|
|
|
|
|
{
|
|
|
|
|
appendPQExpBuffer(sql, "%sFREEZE", sep);
|
|
|
|
|
sep = comma;
|
|
|
|
|
}
|
|
|
|
|
if (vacopts->verbose)
|
|
|
|
|
{
|
|
|
|
|
appendPQExpBuffer(sql, "%sVERBOSE", sep);
|
|
|
|
|
sep = comma;
|
|
|
|
|
}
|
|
|
|
|
if (vacopts->and_analyze)
|
|
|
|
|
{
|
|
|
|
|
appendPQExpBuffer(sql, "%sANALYZE", sep);
|
|
|
|
|
sep = comma;
|
|
|
|
|
}
|
|
|
|
|
if (vacopts->parallel_workers >= 0)
|
|
|
|
|
{
|
|
|
|
|
/* PARALLEL is supported since v13 */
|
|
|
|
|
Assert(serverVersion >= 130000);
|
|
|
|
|
appendPQExpBuffer(sql, "%sPARALLEL %d", sep,
|
|
|
|
|
vacopts->parallel_workers);
|
|
|
|
|
sep = comma;
|
|
|
|
|
}
|
|
|
|
|
if (vacopts->buffer_usage_limit)
|
|
|
|
|
{
|
|
|
|
|
Assert(serverVersion >= 160000);
|
|
|
|
|
appendPQExpBuffer(sql, "%sBUFFER_USAGE_LIMIT '%s'", sep,
|
|
|
|
|
vacopts->buffer_usage_limit);
|
|
|
|
|
sep = comma;
|
|
|
|
|
}
|
|
|
|
|
if (sep != paren)
|
|
|
|
|
appendPQExpBufferChar(sql, ')');
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
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");
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
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
7 years ago
|
|
|
appendPQExpBuffer(sql, " %s;", table);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Send a vacuum/analyze command to the server, returning after sending the
|
|
|
|
|
* command.
|
|
|
|
|
*
|
|
|
|
|
* Any errors during command execution are reported to stderr.
|
|
|
|
|
*/
|
|
|
|
|
static void
|
|
|
|
|
run_vacuum_command(PGconn *conn, const char *sql, bool echo,
|
|
|
|
|
const char *table)
|
|
|
|
|
{
|
|
|
|
|
bool status;
|
|
|
|
|
|
|
|
|
|
if (echo)
|
|
|
|
|
printf("%s\n", sql);
|
|
|
|
|
|
|
|
|
|
status = PQsendQuery(conn, sql) == 1;
|
|
|
|
|
|
|
|
|
|
if (!status)
|
|
|
|
|
{
|
|
|
|
|
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
7 years ago
|
|
|
pg_log_error("vacuuming of table \"%s\" in database \"%s\" failed: %s",
|
|
|
|
|
table, PQdb(conn), PQerrorMessage(conn));
|
|
|
|
|
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
7 years ago
|
|
|
pg_log_error("vacuuming of database \"%s\" failed: %s",
|
|
|
|
|
PQdb(conn), PQerrorMessage(conn));
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
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(_(" --buffer-usage-limit=SIZE size of ring buffer used for vacuum\n"));
|
|
|
|
|
printf(_(" -d, --dbname=DBNAME database to vacuum\n"));
|
|
|
|
|
printf(_(" --disable-page-skipping disable all page-skipping behavior\n"));
|
|
|
|
|
printf(_(" -e, --echo show the commands being sent to the server\n"));
|
|
|
|
|
printf(_(" -f, --full do full vacuuming\n"));
|
|
|
|
|
printf(_(" -F, --freeze freeze row transaction information\n"));
|
|
|
|
|
printf(_(" --force-index-cleanup always remove index entries that point to dead tuples\n"));
|
|
|
|
|
printf(_(" -j, --jobs=NUM use this many concurrent connections to vacuum\n"));
|
|
|
|
|
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"));
|
|
|
|
|
printf(_(" --no-index-cleanup don't remove index entries that point to dead tuples\n"));
|
|
|
|
|
printf(_(" --no-process-main skip the main relation\n"));
|
|
|
|
|
printf(_(" --no-process-toast skip the TOAST table associated with the table to vacuum\n"));
|
|
|
|
|
printf(_(" --no-truncate don't truncate empty pages at the end of the table\n"));
|
|
|
|
|
printf(_(" -n, --schema=SCHEMA vacuum tables in the specified schema(s) only\n"));
|
|
|
|
|
printf(_(" -N, --exclude-schema=SCHEMA do not vacuum tables in the specified schema(s)\n"));
|
|
|
|
|
printf(_(" -P, --parallel=PARALLEL_WORKERS use this many background workers for vacuum, if available\n"));
|
|
|
|
|
printf(_(" -q, --quiet don't write any messages\n"));
|
|
|
|
|
printf(_(" --skip-locked skip relations that cannot be immediately locked\n"));
|
|
|
|
|
printf(_(" -t, --table='TABLE[(COLUMNS)]' vacuum specific table(s) only\n"));
|
|
|
|
|
printf(_(" -v, --verbose write a lot of output\n"));
|
|
|
|
|
printf(_(" -V, --version output version information, then exit\n"));
|
|
|
|
|
printf(_(" -z, --analyze update optimizer statistics\n"));
|
|
|
|
|
printf(_(" -Z, --analyze-only only update optimizer statistics; no vacuum\n"));
|
|
|
|
|
printf(_(" --analyze-in-stages only update optimizer statistics, in multiple\n"
|
|
|
|
|
" stages for faster results; no vacuum\n"));
|
|
|
|
|
printf(_(" -?, --help show this help, then exit\n"));
|
|
|
|
|
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"));
|
|
|
|
|
printf(_(" -w, --no-password never prompt for password\n"));
|
|
|
|
|
printf(_(" -W, --password force password prompt\n"));
|
|
|
|
|
printf(_(" --maintenance-db=DBNAME alternate maintenance database\n"));
|
|
|
|
|
printf(_("\nRead the description of the SQL command VACUUM for details.\n"));
|
|
|
|
|
printf(_("\nReport bugs to <%s>.\n"), PACKAGE_BUGREPORT);
|
|
|
|
|
printf(_("%s home page: <%s>\n"), PACKAGE_NAME, PACKAGE_URL);
|
|
|
|
|
}
|