2016-03-05 20:10:19 +01:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
|
|
|
* pg_controldata.c
|
|
|
|
*
|
|
|
|
* Routines to expose the contents of the control data file via
|
|
|
|
* a set of SQL functions.
|
|
|
|
*
|
2019-01-02 18:44:25 +01:00
|
|
|
* Portions Copyright (c) 1996-2019, PostgreSQL Global Development Group
|
2016-03-05 20:10:19 +01:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
|
|
|
*
|
|
|
|
* IDENTIFICATION
|
|
|
|
* src/backend/utils/misc/pg_controldata.c
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "postgres.h"
|
|
|
|
|
|
|
|
#include "access/htup_details.h"
|
2019-03-27 22:34:43 +01:00
|
|
|
#include "access/transam.h"
|
2018-04-15 02:12:14 +02:00
|
|
|
#include "access/xlog.h"
|
2019-11-12 04:00:16 +01:00
|
|
|
#include "access/xlog_internal.h"
|
2016-03-05 20:10:19 +01:00
|
|
|
#include "catalog/pg_control.h"
|
|
|
|
#include "catalog/pg_type.h"
|
|
|
|
#include "common/controldata_utils.h"
|
2018-04-15 02:12:14 +02:00
|
|
|
#include "funcapi.h"
|
|
|
|
#include "miscadmin.h"
|
2016-03-05 20:10:19 +01:00
|
|
|
#include "utils/builtins.h"
|
|
|
|
#include "utils/pg_lsn.h"
|
|
|
|
#include "utils/timestamp.h"
|
|
|
|
|
|
|
|
Datum
|
|
|
|
pg_control_system(PG_FUNCTION_ARGS)
|
|
|
|
{
|
2016-06-10 00:02:36 +02:00
|
|
|
Datum values[4];
|
|
|
|
bool nulls[4];
|
|
|
|
TupleDesc tupdesc;
|
|
|
|
HeapTuple htup;
|
|
|
|
ControlFileData *ControlFile;
|
2016-09-28 18:00:00 +02:00
|
|
|
bool crc_ok;
|
2016-03-05 20:10:19 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Construct a tuple descriptor for the result row. This must match this
|
|
|
|
* function's pg_proc entry!
|
|
|
|
*/
|
Remove WITH OIDS support, change oid catalog column visibility.
Previously tables declared WITH OIDS, including a significant fraction
of the catalog tables, stored the oid column not as a normal column,
but as part of the tuple header.
This special column was not shown by default, which was somewhat odd,
as it's often (consider e.g. pg_class.oid) one of the more important
parts of a row. Neither pg_dump nor COPY included the contents of the
oid column by default.
The fact that the oid column was not an ordinary column necessitated a
significant amount of special case code to support oid columns. That
already was painful for the existing, but upcoming work aiming to make
table storage pluggable, would have required expanding and duplicating
that "specialness" significantly.
WITH OIDS has been deprecated since 2005 (commit ff02d0a05280e0).
Remove it.
Removing includes:
- CREATE TABLE and ALTER TABLE syntax for declaring the table to be
WITH OIDS has been removed (WITH (oids[ = true]) will error out)
- pg_dump does not support dumping tables declared WITH OIDS and will
issue a warning when dumping one (and ignore the oid column).
- restoring an pg_dump archive with pg_restore will warn when
restoring a table with oid contents (and ignore the oid column)
- COPY will refuse to load binary dump that includes oids.
- pg_upgrade will error out when encountering tables declared WITH
OIDS, they have to be altered to remove the oid column first.
- Functionality to access the oid of the last inserted row (like
plpgsql's RESULT_OID, spi's SPI_lastoid, ...) has been removed.
The syntax for declaring a table WITHOUT OIDS (or WITH (oids = false)
for CREATE TABLE) is still supported. While that requires a bit of
support code, it seems unnecessary to break applications / dumps that
do not use oids, and are explicit about not using them.
The biggest user of WITH OID columns was postgres' catalog. This
commit changes all 'magic' oid columns to be columns that are normally
declared and stored. To reduce unnecessary query breakage all the
newly added columns are still named 'oid', even if a table's column
naming scheme would indicate 'reloid' or such. This obviously
requires adapting a lot code, mostly replacing oid access via
HeapTupleGetOid() with access to the underlying Form_pg_*->oid column.
The bootstrap process now assigns oids for all oid columns in
genbki.pl that do not have an explicit value (starting at the largest
oid previously used), only oids assigned later by oids will be above
FirstBootstrapObjectId. As the oid column now is a normal column the
special bootstrap syntax for oids has been removed.
Oids are not automatically assigned during insertion anymore, all
backend code explicitly assigns oids with GetNewOidWithIndex(). For
the rare case that insertions into the catalog via SQL are called for
the new pg_nextoid() function can be used (which only works on catalog
tables).
The fact that oid columns on system tables are now normal columns
means that they will be included in the set of columns expanded
by * (i.e. SELECT * FROM pg_class will now include the table's oid,
previously it did not). It'd not technically be hard to hide oid
column by default, but that'd mean confusing behavior would either
have to be carried forward forever, or it'd cause breakage down the
line.
While it's not unlikely that further adjustments are needed, the
scope/invasiveness of the patch makes it worthwhile to get merge this
now. It's painful to maintain externally, too complicated to commit
after the code code freeze, and a dependency of a number of other
patches.
Catversion bump, for obvious reasons.
Author: Andres Freund, with contributions by John Naylor
Discussion: https://postgr.es/m/20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de
2018-11-21 00:36:57 +01:00
|
|
|
tupdesc = CreateTemplateTupleDesc(4);
|
2016-03-05 20:10:19 +01:00
|
|
|
TupleDescInitEntry(tupdesc, (AttrNumber) 1, "pg_control_version",
|
|
|
|
INT4OID, -1, 0);
|
|
|
|
TupleDescInitEntry(tupdesc, (AttrNumber) 2, "catalog_version_no",
|
|
|
|
INT4OID, -1, 0);
|
|
|
|
TupleDescInitEntry(tupdesc, (AttrNumber) 3, "system_identifier",
|
|
|
|
INT8OID, -1, 0);
|
|
|
|
TupleDescInitEntry(tupdesc, (AttrNumber) 4, "pg_control_last_modified",
|
|
|
|
TIMESTAMPTZOID, -1, 0);
|
|
|
|
tupdesc = BlessTupleDesc(tupdesc);
|
|
|
|
|
|
|
|
/* read the control file */
|
Unified logging system for command-line programs
This unifies the various ad hoc logging (message printing, error
printing) systems used throughout the command-line programs.
Features:
- Program name is automatically prefixed.
- Message string does not end with newline. This removes a common
source of inconsistencies and omissions.
- Additionally, a final newline is automatically stripped, simplifying
use of PQerrorMessage() etc., another common source of mistakes.
- I converted error message strings to use %m where possible.
- As a result of the above several points, more translatable message
strings can be shared between different components and between
frontends and backend, without gratuitous punctuation or whitespace
differences.
- There is support for setting a "log level". This is not meant to be
user-facing, but can be used internally to implement debug or
verbose modes.
- Lazy argument evaluation, so no significant overhead if logging at
some level is disabled.
- Some color in the messages, similar to gcc and clang. Set
PG_COLOR=auto to try it out. Some colors are predefined, but can be
customized by setting PG_COLORS.
- Common files (common/, fe_utils/, etc.) can handle logging much more
simply by just using one API without worrying too much about the
context of the calling program, requiring callbacks, or having to
pass "progname" around everywhere.
- Some programs called setvbuf() to make sure that stderr is
unbuffered, even on Windows. But not all programs did that. This
is now done centrally.
Soft goals:
- Reduces vertical space use and visual complexity of error reporting
in the source code.
- Encourages more deliberate classification of messages. For example,
in some cases it wasn't clear without analyzing the surrounding code
whether a message was meant as an error or just an info.
- Concepts and terms are vaguely aligned with popular logging
frameworks such as log4j and Python logging.
This is all just about printing stuff out. Nothing affects program
flow (e.g., fatal exits). The uses are just too varied to do that.
Some existing code had wrappers that do some kind of print-and-exit,
and I adapted those.
I tried to keep the output mostly the same, but there is a lot of
historical baggage to unwind and special cases to consider, and I
might not always have succeeded. One significant change is that
pg_rewind used to write all error messages to stdout. That is now
changed to stderr.
Reviewed-by: Donald Dong <xdong@csumb.edu>
Reviewed-by: Arthur Zakirov <a.zakirov@postgrespro.ru>
Discussion: https://www.postgresql.org/message-id/flat/6a609b43-4f57-7348-6480-bd022f924310@2ndquadrant.com
2019-04-01 14:24:37 +02:00
|
|
|
ControlFile = get_controlfile(DataDir, &crc_ok);
|
2016-09-28 18:00:00 +02:00
|
|
|
if (!crc_ok)
|
2016-07-26 17:23:43 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errmsg("calculated CRC checksum does not match value stored in file")));
|
2016-03-05 20:10:19 +01:00
|
|
|
|
|
|
|
values[0] = Int32GetDatum(ControlFile->pg_control_version);
|
|
|
|
nulls[0] = false;
|
|
|
|
|
|
|
|
values[1] = Int32GetDatum(ControlFile->catalog_version_no);
|
|
|
|
nulls[1] = false;
|
|
|
|
|
|
|
|
values[2] = Int64GetDatum(ControlFile->system_identifier);
|
|
|
|
nulls[2] = false;
|
|
|
|
|
|
|
|
values[3] = TimestampTzGetDatum(time_t_to_timestamptz(ControlFile->time));
|
|
|
|
nulls[3] = false;
|
|
|
|
|
|
|
|
htup = heap_form_tuple(tupdesc, values, nulls);
|
|
|
|
|
|
|
|
PG_RETURN_DATUM(HeapTupleGetDatum(htup));
|
|
|
|
}
|
|
|
|
|
|
|
|
Datum
|
|
|
|
pg_control_checkpoint(PG_FUNCTION_ARGS)
|
|
|
|
{
|
2016-06-10 00:02:36 +02:00
|
|
|
Datum values[19];
|
|
|
|
bool nulls[19];
|
|
|
|
TupleDesc tupdesc;
|
|
|
|
HeapTuple htup;
|
|
|
|
ControlFileData *ControlFile;
|
|
|
|
XLogSegNo segno;
|
|
|
|
char xlogfilename[MAXFNAMELEN];
|
2016-09-28 18:00:00 +02:00
|
|
|
bool crc_ok;
|
2016-03-05 20:10:19 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Construct a tuple descriptor for the result row. This must match this
|
|
|
|
* function's pg_proc entry!
|
|
|
|
*/
|
Remove WITH OIDS support, change oid catalog column visibility.
Previously tables declared WITH OIDS, including a significant fraction
of the catalog tables, stored the oid column not as a normal column,
but as part of the tuple header.
This special column was not shown by default, which was somewhat odd,
as it's often (consider e.g. pg_class.oid) one of the more important
parts of a row. Neither pg_dump nor COPY included the contents of the
oid column by default.
The fact that the oid column was not an ordinary column necessitated a
significant amount of special case code to support oid columns. That
already was painful for the existing, but upcoming work aiming to make
table storage pluggable, would have required expanding and duplicating
that "specialness" significantly.
WITH OIDS has been deprecated since 2005 (commit ff02d0a05280e0).
Remove it.
Removing includes:
- CREATE TABLE and ALTER TABLE syntax for declaring the table to be
WITH OIDS has been removed (WITH (oids[ = true]) will error out)
- pg_dump does not support dumping tables declared WITH OIDS and will
issue a warning when dumping one (and ignore the oid column).
- restoring an pg_dump archive with pg_restore will warn when
restoring a table with oid contents (and ignore the oid column)
- COPY will refuse to load binary dump that includes oids.
- pg_upgrade will error out when encountering tables declared WITH
OIDS, they have to be altered to remove the oid column first.
- Functionality to access the oid of the last inserted row (like
plpgsql's RESULT_OID, spi's SPI_lastoid, ...) has been removed.
The syntax for declaring a table WITHOUT OIDS (or WITH (oids = false)
for CREATE TABLE) is still supported. While that requires a bit of
support code, it seems unnecessary to break applications / dumps that
do not use oids, and are explicit about not using them.
The biggest user of WITH OID columns was postgres' catalog. This
commit changes all 'magic' oid columns to be columns that are normally
declared and stored. To reduce unnecessary query breakage all the
newly added columns are still named 'oid', even if a table's column
naming scheme would indicate 'reloid' or such. This obviously
requires adapting a lot code, mostly replacing oid access via
HeapTupleGetOid() with access to the underlying Form_pg_*->oid column.
The bootstrap process now assigns oids for all oid columns in
genbki.pl that do not have an explicit value (starting at the largest
oid previously used), only oids assigned later by oids will be above
FirstBootstrapObjectId. As the oid column now is a normal column the
special bootstrap syntax for oids has been removed.
Oids are not automatically assigned during insertion anymore, all
backend code explicitly assigns oids with GetNewOidWithIndex(). For
the rare case that insertions into the catalog via SQL are called for
the new pg_nextoid() function can be used (which only works on catalog
tables).
The fact that oid columns on system tables are now normal columns
means that they will be included in the set of columns expanded
by * (i.e. SELECT * FROM pg_class will now include the table's oid,
previously it did not). It'd not technically be hard to hide oid
column by default, but that'd mean confusing behavior would either
have to be carried forward forever, or it'd cause breakage down the
line.
While it's not unlikely that further adjustments are needed, the
scope/invasiveness of the patch makes it worthwhile to get merge this
now. It's painful to maintain externally, too complicated to commit
after the code code freeze, and a dependency of a number of other
patches.
Catversion bump, for obvious reasons.
Author: Andres Freund, with contributions by John Naylor
Discussion: https://postgr.es/m/20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de
2018-11-21 00:36:57 +01:00
|
|
|
tupdesc = CreateTemplateTupleDesc(18);
|
2017-05-11 17:49:59 +02:00
|
|
|
TupleDescInitEntry(tupdesc, (AttrNumber) 1, "checkpoint_lsn",
|
2016-03-05 20:10:19 +01:00
|
|
|
LSNOID, -1, 0);
|
2017-11-07 18:56:30 +01:00
|
|
|
TupleDescInitEntry(tupdesc, (AttrNumber) 2, "redo_lsn",
|
2016-03-05 20:10:19 +01:00
|
|
|
LSNOID, -1, 0);
|
2017-11-07 18:56:30 +01:00
|
|
|
TupleDescInitEntry(tupdesc, (AttrNumber) 3, "redo_wal_file",
|
2016-03-05 20:10:19 +01:00
|
|
|
TEXTOID, -1, 0);
|
2017-11-07 18:56:30 +01:00
|
|
|
TupleDescInitEntry(tupdesc, (AttrNumber) 4, "timeline_id",
|
2016-03-05 20:10:19 +01:00
|
|
|
INT4OID, -1, 0);
|
2017-11-07 18:56:30 +01:00
|
|
|
TupleDescInitEntry(tupdesc, (AttrNumber) 5, "prev_timeline_id",
|
2016-03-05 20:10:19 +01:00
|
|
|
INT4OID, -1, 0);
|
2017-11-07 18:56:30 +01:00
|
|
|
TupleDescInitEntry(tupdesc, (AttrNumber) 6, "full_page_writes",
|
2016-03-05 20:10:19 +01:00
|
|
|
BOOLOID, -1, 0);
|
2017-11-07 18:56:30 +01:00
|
|
|
TupleDescInitEntry(tupdesc, (AttrNumber) 7, "next_xid",
|
2016-03-05 20:10:19 +01:00
|
|
|
TEXTOID, -1, 0);
|
2017-11-07 18:56:30 +01:00
|
|
|
TupleDescInitEntry(tupdesc, (AttrNumber) 8, "next_oid",
|
2016-03-05 20:10:19 +01:00
|
|
|
OIDOID, -1, 0);
|
2017-11-07 18:56:30 +01:00
|
|
|
TupleDescInitEntry(tupdesc, (AttrNumber) 9, "next_multixact_id",
|
2016-03-05 20:10:19 +01:00
|
|
|
XIDOID, -1, 0);
|
2017-11-07 18:56:30 +01:00
|
|
|
TupleDescInitEntry(tupdesc, (AttrNumber) 10, "next_multi_offset",
|
2016-03-05 20:10:19 +01:00
|
|
|
XIDOID, -1, 0);
|
2017-11-07 18:56:30 +01:00
|
|
|
TupleDescInitEntry(tupdesc, (AttrNumber) 11, "oldest_xid",
|
2016-03-05 20:10:19 +01:00
|
|
|
XIDOID, -1, 0);
|
2017-11-07 18:56:30 +01:00
|
|
|
TupleDescInitEntry(tupdesc, (AttrNumber) 12, "oldest_xid_dbid",
|
2016-03-05 20:10:19 +01:00
|
|
|
OIDOID, -1, 0);
|
2017-11-07 18:56:30 +01:00
|
|
|
TupleDescInitEntry(tupdesc, (AttrNumber) 13, "oldest_active_xid",
|
2016-03-05 20:10:19 +01:00
|
|
|
XIDOID, -1, 0);
|
2017-11-07 18:56:30 +01:00
|
|
|
TupleDescInitEntry(tupdesc, (AttrNumber) 14, "oldest_multi_xid",
|
2016-03-05 20:10:19 +01:00
|
|
|
XIDOID, -1, 0);
|
2017-11-07 18:56:30 +01:00
|
|
|
TupleDescInitEntry(tupdesc, (AttrNumber) 15, "oldest_multi_dbid",
|
2016-03-05 20:10:19 +01:00
|
|
|
OIDOID, -1, 0);
|
2017-11-07 18:56:30 +01:00
|
|
|
TupleDescInitEntry(tupdesc, (AttrNumber) 16, "oldest_commit_ts_xid",
|
2016-03-05 20:10:19 +01:00
|
|
|
XIDOID, -1, 0);
|
2017-11-07 18:56:30 +01:00
|
|
|
TupleDescInitEntry(tupdesc, (AttrNumber) 17, "newest_commit_ts_xid",
|
2016-03-05 20:10:19 +01:00
|
|
|
XIDOID, -1, 0);
|
2017-11-07 18:56:30 +01:00
|
|
|
TupleDescInitEntry(tupdesc, (AttrNumber) 18, "checkpoint_time",
|
2016-03-05 20:10:19 +01:00
|
|
|
TIMESTAMPTZOID, -1, 0);
|
|
|
|
tupdesc = BlessTupleDesc(tupdesc);
|
|
|
|
|
|
|
|
/* Read the control file. */
|
Unified logging system for command-line programs
This unifies the various ad hoc logging (message printing, error
printing) systems used throughout the command-line programs.
Features:
- Program name is automatically prefixed.
- Message string does not end with newline. This removes a common
source of inconsistencies and omissions.
- Additionally, a final newline is automatically stripped, simplifying
use of PQerrorMessage() etc., another common source of mistakes.
- I converted error message strings to use %m where possible.
- As a result of the above several points, more translatable message
strings can be shared between different components and between
frontends and backend, without gratuitous punctuation or whitespace
differences.
- There is support for setting a "log level". This is not meant to be
user-facing, but can be used internally to implement debug or
verbose modes.
- Lazy argument evaluation, so no significant overhead if logging at
some level is disabled.
- Some color in the messages, similar to gcc and clang. Set
PG_COLOR=auto to try it out. Some colors are predefined, but can be
customized by setting PG_COLORS.
- Common files (common/, fe_utils/, etc.) can handle logging much more
simply by just using one API without worrying too much about the
context of the calling program, requiring callbacks, or having to
pass "progname" around everywhere.
- Some programs called setvbuf() to make sure that stderr is
unbuffered, even on Windows. But not all programs did that. This
is now done centrally.
Soft goals:
- Reduces vertical space use and visual complexity of error reporting
in the source code.
- Encourages more deliberate classification of messages. For example,
in some cases it wasn't clear without analyzing the surrounding code
whether a message was meant as an error or just an info.
- Concepts and terms are vaguely aligned with popular logging
frameworks such as log4j and Python logging.
This is all just about printing stuff out. Nothing affects program
flow (e.g., fatal exits). The uses are just too varied to do that.
Some existing code had wrappers that do some kind of print-and-exit,
and I adapted those.
I tried to keep the output mostly the same, but there is a lot of
historical baggage to unwind and special cases to consider, and I
might not always have succeeded. One significant change is that
pg_rewind used to write all error messages to stdout. That is now
changed to stderr.
Reviewed-by: Donald Dong <xdong@csumb.edu>
Reviewed-by: Arthur Zakirov <a.zakirov@postgrespro.ru>
Discussion: https://www.postgresql.org/message-id/flat/6a609b43-4f57-7348-6480-bd022f924310@2ndquadrant.com
2019-04-01 14:24:37 +02:00
|
|
|
ControlFile = get_controlfile(DataDir, &crc_ok);
|
2016-09-28 18:00:00 +02:00
|
|
|
if (!crc_ok)
|
2016-07-26 17:23:43 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errmsg("calculated CRC checksum does not match value stored in file")));
|
2016-03-05 20:10:19 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Calculate name of the WAL file containing the latest checkpoint's REDO
|
|
|
|
* start point.
|
|
|
|
*/
|
Make WAL segment size configurable at initdb time.
For performance reasons a larger segment size than the default 16MB
can be useful. A larger segment size has two main benefits: Firstly,
in setups using archiving, it makes it easier to write scripts that
can keep up with higher amounts of WAL, secondly, the WAL has to be
written and synced to disk less frequently.
But at the same time large segment size are disadvantageous for
smaller databases. So far the segment size had to be configured at
compile time, often making it unrealistic to choose one fitting to a
particularly load. Therefore change it to a initdb time setting.
This includes a breaking changes to the xlogreader.h API, which now
requires the current segment size to be configured. For that and
similar reasons a number of binaries had to be taught how to recognize
the current segment size.
Author: Beena Emerson, editorialized by Andres Freund
Reviewed-By: Andres Freund, David Steele, Kuntal Ghosh, Michael
Paquier, Peter Eisentraut, Robert Hass, Tushar Ahuja
Discussion: https://postgr.es/m/CAOG9ApEAcQ--1ieKbhFzXSQPw_YLmepaa4hNdnY5+ZULpt81Mw@mail.gmail.com
2017-09-20 07:03:48 +02:00
|
|
|
XLByteToSeg(ControlFile->checkPointCopy.redo, segno, wal_segment_size);
|
|
|
|
XLogFileName(xlogfilename, ControlFile->checkPointCopy.ThisTimeLineID,
|
|
|
|
segno, wal_segment_size);
|
2016-03-05 20:10:19 +01:00
|
|
|
|
|
|
|
/* Populate the values and null arrays */
|
|
|
|
values[0] = LSNGetDatum(ControlFile->checkPoint);
|
|
|
|
nulls[0] = false;
|
|
|
|
|
2017-11-07 18:56:30 +01:00
|
|
|
values[1] = LSNGetDatum(ControlFile->checkPointCopy.redo);
|
2016-03-05 20:10:19 +01:00
|
|
|
nulls[1] = false;
|
|
|
|
|
2017-11-07 18:56:30 +01:00
|
|
|
values[2] = CStringGetTextDatum(xlogfilename);
|
2016-03-05 20:10:19 +01:00
|
|
|
nulls[2] = false;
|
|
|
|
|
2017-11-07 18:56:30 +01:00
|
|
|
values[3] = Int32GetDatum(ControlFile->checkPointCopy.ThisTimeLineID);
|
2016-03-05 20:10:19 +01:00
|
|
|
nulls[3] = false;
|
|
|
|
|
2017-11-07 18:56:30 +01:00
|
|
|
values[4] = Int32GetDatum(ControlFile->checkPointCopy.PrevTimeLineID);
|
2016-03-05 20:10:19 +01:00
|
|
|
nulls[4] = false;
|
|
|
|
|
2017-11-07 18:56:30 +01:00
|
|
|
values[5] = BoolGetDatum(ControlFile->checkPointCopy.fullPageWrites);
|
2016-03-05 20:10:19 +01:00
|
|
|
nulls[5] = false;
|
|
|
|
|
2017-11-07 18:56:30 +01:00
|
|
|
values[6] = CStringGetTextDatum(psprintf("%u:%u",
|
2019-03-27 22:34:43 +01:00
|
|
|
EpochFromFullTransactionId(ControlFile->checkPointCopy.nextFullXid),
|
|
|
|
XidFromFullTransactionId(ControlFile->checkPointCopy.nextFullXid)));
|
2017-11-07 18:56:30 +01:00
|
|
|
nulls[6] = false;
|
|
|
|
|
|
|
|
values[7] = ObjectIdGetDatum(ControlFile->checkPointCopy.nextOid);
|
2016-03-05 20:10:19 +01:00
|
|
|
nulls[7] = false;
|
|
|
|
|
2017-11-07 18:56:30 +01:00
|
|
|
values[8] = TransactionIdGetDatum(ControlFile->checkPointCopy.nextMulti);
|
2016-03-05 20:10:19 +01:00
|
|
|
nulls[8] = false;
|
|
|
|
|
2017-11-07 18:56:30 +01:00
|
|
|
values[9] = TransactionIdGetDatum(ControlFile->checkPointCopy.nextMultiOffset);
|
2016-03-05 20:10:19 +01:00
|
|
|
nulls[9] = false;
|
|
|
|
|
2017-11-07 18:56:30 +01:00
|
|
|
values[10] = TransactionIdGetDatum(ControlFile->checkPointCopy.oldestXid);
|
2016-03-05 20:10:19 +01:00
|
|
|
nulls[10] = false;
|
|
|
|
|
2017-11-07 18:56:30 +01:00
|
|
|
values[11] = ObjectIdGetDatum(ControlFile->checkPointCopy.oldestXidDB);
|
2016-03-05 20:10:19 +01:00
|
|
|
nulls[11] = false;
|
|
|
|
|
2017-11-07 18:56:30 +01:00
|
|
|
values[12] = TransactionIdGetDatum(ControlFile->checkPointCopy.oldestActiveXid);
|
2016-03-05 20:10:19 +01:00
|
|
|
nulls[12] = false;
|
|
|
|
|
2017-11-07 18:56:30 +01:00
|
|
|
values[13] = TransactionIdGetDatum(ControlFile->checkPointCopy.oldestMulti);
|
2016-03-05 20:10:19 +01:00
|
|
|
nulls[13] = false;
|
|
|
|
|
2017-11-07 18:56:30 +01:00
|
|
|
values[14] = ObjectIdGetDatum(ControlFile->checkPointCopy.oldestMultiDB);
|
2016-03-05 20:10:19 +01:00
|
|
|
nulls[14] = false;
|
|
|
|
|
2017-11-07 18:56:30 +01:00
|
|
|
values[15] = TransactionIdGetDatum(ControlFile->checkPointCopy.oldestCommitTsXid);
|
2016-03-05 20:10:19 +01:00
|
|
|
nulls[15] = false;
|
|
|
|
|
2017-11-07 18:56:30 +01:00
|
|
|
values[16] = TransactionIdGetDatum(ControlFile->checkPointCopy.newestCommitTsXid);
|
2016-03-05 20:10:19 +01:00
|
|
|
nulls[16] = false;
|
|
|
|
|
2017-11-07 18:56:30 +01:00
|
|
|
values[17] = TimestampTzGetDatum(
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
time_t_to_timestamptz(ControlFile->checkPointCopy.time));
|
2017-11-07 18:56:30 +01:00
|
|
|
nulls[17] = false;
|
2016-03-05 20:10:19 +01:00
|
|
|
|
|
|
|
htup = heap_form_tuple(tupdesc, values, nulls);
|
|
|
|
|
|
|
|
PG_RETURN_DATUM(HeapTupleGetDatum(htup));
|
|
|
|
}
|
|
|
|
|
|
|
|
Datum
|
|
|
|
pg_control_recovery(PG_FUNCTION_ARGS)
|
|
|
|
{
|
2016-06-10 00:02:36 +02:00
|
|
|
Datum values[5];
|
|
|
|
bool nulls[5];
|
|
|
|
TupleDesc tupdesc;
|
|
|
|
HeapTuple htup;
|
|
|
|
ControlFileData *ControlFile;
|
2016-09-28 18:00:00 +02:00
|
|
|
bool crc_ok;
|
2016-03-05 20:10:19 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Construct a tuple descriptor for the result row. This must match this
|
|
|
|
* function's pg_proc entry!
|
|
|
|
*/
|
Remove WITH OIDS support, change oid catalog column visibility.
Previously tables declared WITH OIDS, including a significant fraction
of the catalog tables, stored the oid column not as a normal column,
but as part of the tuple header.
This special column was not shown by default, which was somewhat odd,
as it's often (consider e.g. pg_class.oid) one of the more important
parts of a row. Neither pg_dump nor COPY included the contents of the
oid column by default.
The fact that the oid column was not an ordinary column necessitated a
significant amount of special case code to support oid columns. That
already was painful for the existing, but upcoming work aiming to make
table storage pluggable, would have required expanding and duplicating
that "specialness" significantly.
WITH OIDS has been deprecated since 2005 (commit ff02d0a05280e0).
Remove it.
Removing includes:
- CREATE TABLE and ALTER TABLE syntax for declaring the table to be
WITH OIDS has been removed (WITH (oids[ = true]) will error out)
- pg_dump does not support dumping tables declared WITH OIDS and will
issue a warning when dumping one (and ignore the oid column).
- restoring an pg_dump archive with pg_restore will warn when
restoring a table with oid contents (and ignore the oid column)
- COPY will refuse to load binary dump that includes oids.
- pg_upgrade will error out when encountering tables declared WITH
OIDS, they have to be altered to remove the oid column first.
- Functionality to access the oid of the last inserted row (like
plpgsql's RESULT_OID, spi's SPI_lastoid, ...) has been removed.
The syntax for declaring a table WITHOUT OIDS (or WITH (oids = false)
for CREATE TABLE) is still supported. While that requires a bit of
support code, it seems unnecessary to break applications / dumps that
do not use oids, and are explicit about not using them.
The biggest user of WITH OID columns was postgres' catalog. This
commit changes all 'magic' oid columns to be columns that are normally
declared and stored. To reduce unnecessary query breakage all the
newly added columns are still named 'oid', even if a table's column
naming scheme would indicate 'reloid' or such. This obviously
requires adapting a lot code, mostly replacing oid access via
HeapTupleGetOid() with access to the underlying Form_pg_*->oid column.
The bootstrap process now assigns oids for all oid columns in
genbki.pl that do not have an explicit value (starting at the largest
oid previously used), only oids assigned later by oids will be above
FirstBootstrapObjectId. As the oid column now is a normal column the
special bootstrap syntax for oids has been removed.
Oids are not automatically assigned during insertion anymore, all
backend code explicitly assigns oids with GetNewOidWithIndex(). For
the rare case that insertions into the catalog via SQL are called for
the new pg_nextoid() function can be used (which only works on catalog
tables).
The fact that oid columns on system tables are now normal columns
means that they will be included in the set of columns expanded
by * (i.e. SELECT * FROM pg_class will now include the table's oid,
previously it did not). It'd not technically be hard to hide oid
column by default, but that'd mean confusing behavior would either
have to be carried forward forever, or it'd cause breakage down the
line.
While it's not unlikely that further adjustments are needed, the
scope/invasiveness of the patch makes it worthwhile to get merge this
now. It's painful to maintain externally, too complicated to commit
after the code code freeze, and a dependency of a number of other
patches.
Catversion bump, for obvious reasons.
Author: Andres Freund, with contributions by John Naylor
Discussion: https://postgr.es/m/20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de
2018-11-21 00:36:57 +01:00
|
|
|
tupdesc = CreateTemplateTupleDesc(5);
|
2017-05-11 17:49:59 +02:00
|
|
|
TupleDescInitEntry(tupdesc, (AttrNumber) 1, "min_recovery_end_lsn",
|
2016-03-05 20:10:19 +01:00
|
|
|
LSNOID, -1, 0);
|
|
|
|
TupleDescInitEntry(tupdesc, (AttrNumber) 2, "min_recovery_end_timeline",
|
|
|
|
INT4OID, -1, 0);
|
2017-05-11 17:49:59 +02:00
|
|
|
TupleDescInitEntry(tupdesc, (AttrNumber) 3, "backup_start_lsn",
|
2016-03-05 20:10:19 +01:00
|
|
|
LSNOID, -1, 0);
|
2017-05-11 17:49:59 +02:00
|
|
|
TupleDescInitEntry(tupdesc, (AttrNumber) 4, "backup_end_lsn",
|
2016-03-05 20:10:19 +01:00
|
|
|
LSNOID, -1, 0);
|
|
|
|
TupleDescInitEntry(tupdesc, (AttrNumber) 5, "end_of_backup_record_required",
|
|
|
|
BOOLOID, -1, 0);
|
|
|
|
tupdesc = BlessTupleDesc(tupdesc);
|
|
|
|
|
|
|
|
/* read the control file */
|
Unified logging system for command-line programs
This unifies the various ad hoc logging (message printing, error
printing) systems used throughout the command-line programs.
Features:
- Program name is automatically prefixed.
- Message string does not end with newline. This removes a common
source of inconsistencies and omissions.
- Additionally, a final newline is automatically stripped, simplifying
use of PQerrorMessage() etc., another common source of mistakes.
- I converted error message strings to use %m where possible.
- As a result of the above several points, more translatable message
strings can be shared between different components and between
frontends and backend, without gratuitous punctuation or whitespace
differences.
- There is support for setting a "log level". This is not meant to be
user-facing, but can be used internally to implement debug or
verbose modes.
- Lazy argument evaluation, so no significant overhead if logging at
some level is disabled.
- Some color in the messages, similar to gcc and clang. Set
PG_COLOR=auto to try it out. Some colors are predefined, but can be
customized by setting PG_COLORS.
- Common files (common/, fe_utils/, etc.) can handle logging much more
simply by just using one API without worrying too much about the
context of the calling program, requiring callbacks, or having to
pass "progname" around everywhere.
- Some programs called setvbuf() to make sure that stderr is
unbuffered, even on Windows. But not all programs did that. This
is now done centrally.
Soft goals:
- Reduces vertical space use and visual complexity of error reporting
in the source code.
- Encourages more deliberate classification of messages. For example,
in some cases it wasn't clear without analyzing the surrounding code
whether a message was meant as an error or just an info.
- Concepts and terms are vaguely aligned with popular logging
frameworks such as log4j and Python logging.
This is all just about printing stuff out. Nothing affects program
flow (e.g., fatal exits). The uses are just too varied to do that.
Some existing code had wrappers that do some kind of print-and-exit,
and I adapted those.
I tried to keep the output mostly the same, but there is a lot of
historical baggage to unwind and special cases to consider, and I
might not always have succeeded. One significant change is that
pg_rewind used to write all error messages to stdout. That is now
changed to stderr.
Reviewed-by: Donald Dong <xdong@csumb.edu>
Reviewed-by: Arthur Zakirov <a.zakirov@postgrespro.ru>
Discussion: https://www.postgresql.org/message-id/flat/6a609b43-4f57-7348-6480-bd022f924310@2ndquadrant.com
2019-04-01 14:24:37 +02:00
|
|
|
ControlFile = get_controlfile(DataDir, &crc_ok);
|
2016-09-28 18:00:00 +02:00
|
|
|
if (!crc_ok)
|
2016-07-26 17:23:43 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errmsg("calculated CRC checksum does not match value stored in file")));
|
2016-03-05 20:10:19 +01:00
|
|
|
|
|
|
|
values[0] = LSNGetDatum(ControlFile->minRecoveryPoint);
|
|
|
|
nulls[0] = false;
|
|
|
|
|
|
|
|
values[1] = Int32GetDatum(ControlFile->minRecoveryPointTLI);
|
|
|
|
nulls[1] = false;
|
|
|
|
|
|
|
|
values[2] = LSNGetDatum(ControlFile->backupStartPoint);
|
|
|
|
nulls[2] = false;
|
|
|
|
|
|
|
|
values[3] = LSNGetDatum(ControlFile->backupEndPoint);
|
|
|
|
nulls[3] = false;
|
|
|
|
|
|
|
|
values[4] = BoolGetDatum(ControlFile->backupEndRequired);
|
|
|
|
nulls[4] = false;
|
|
|
|
|
|
|
|
htup = heap_form_tuple(tupdesc, values, nulls);
|
|
|
|
|
|
|
|
PG_RETURN_DATUM(HeapTupleGetDatum(htup));
|
|
|
|
}
|
|
|
|
|
|
|
|
Datum
|
|
|
|
pg_control_init(PG_FUNCTION_ARGS)
|
|
|
|
{
|
2019-11-21 18:00:07 +01:00
|
|
|
Datum values[11];
|
|
|
|
bool nulls[11];
|
2016-06-10 00:02:36 +02:00
|
|
|
TupleDesc tupdesc;
|
|
|
|
HeapTuple htup;
|
|
|
|
ControlFileData *ControlFile;
|
2016-09-28 18:00:00 +02:00
|
|
|
bool crc_ok;
|
2016-03-05 20:10:19 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Construct a tuple descriptor for the result row. This must match this
|
|
|
|
* function's pg_proc entry!
|
|
|
|
*/
|
Remove WITH OIDS support, change oid catalog column visibility.
Previously tables declared WITH OIDS, including a significant fraction
of the catalog tables, stored the oid column not as a normal column,
but as part of the tuple header.
This special column was not shown by default, which was somewhat odd,
as it's often (consider e.g. pg_class.oid) one of the more important
parts of a row. Neither pg_dump nor COPY included the contents of the
oid column by default.
The fact that the oid column was not an ordinary column necessitated a
significant amount of special case code to support oid columns. That
already was painful for the existing, but upcoming work aiming to make
table storage pluggable, would have required expanding and duplicating
that "specialness" significantly.
WITH OIDS has been deprecated since 2005 (commit ff02d0a05280e0).
Remove it.
Removing includes:
- CREATE TABLE and ALTER TABLE syntax for declaring the table to be
WITH OIDS has been removed (WITH (oids[ = true]) will error out)
- pg_dump does not support dumping tables declared WITH OIDS and will
issue a warning when dumping one (and ignore the oid column).
- restoring an pg_dump archive with pg_restore will warn when
restoring a table with oid contents (and ignore the oid column)
- COPY will refuse to load binary dump that includes oids.
- pg_upgrade will error out when encountering tables declared WITH
OIDS, they have to be altered to remove the oid column first.
- Functionality to access the oid of the last inserted row (like
plpgsql's RESULT_OID, spi's SPI_lastoid, ...) has been removed.
The syntax for declaring a table WITHOUT OIDS (or WITH (oids = false)
for CREATE TABLE) is still supported. While that requires a bit of
support code, it seems unnecessary to break applications / dumps that
do not use oids, and are explicit about not using them.
The biggest user of WITH OID columns was postgres' catalog. This
commit changes all 'magic' oid columns to be columns that are normally
declared and stored. To reduce unnecessary query breakage all the
newly added columns are still named 'oid', even if a table's column
naming scheme would indicate 'reloid' or such. This obviously
requires adapting a lot code, mostly replacing oid access via
HeapTupleGetOid() with access to the underlying Form_pg_*->oid column.
The bootstrap process now assigns oids for all oid columns in
genbki.pl that do not have an explicit value (starting at the largest
oid previously used), only oids assigned later by oids will be above
FirstBootstrapObjectId. As the oid column now is a normal column the
special bootstrap syntax for oids has been removed.
Oids are not automatically assigned during insertion anymore, all
backend code explicitly assigns oids with GetNewOidWithIndex(). For
the rare case that insertions into the catalog via SQL are called for
the new pg_nextoid() function can be used (which only works on catalog
tables).
The fact that oid columns on system tables are now normal columns
means that they will be included in the set of columns expanded
by * (i.e. SELECT * FROM pg_class will now include the table's oid,
previously it did not). It'd not technically be hard to hide oid
column by default, but that'd mean confusing behavior would either
have to be carried forward forever, or it'd cause breakage down the
line.
While it's not unlikely that further adjustments are needed, the
scope/invasiveness of the patch makes it worthwhile to get merge this
now. It's painful to maintain externally, too complicated to commit
after the code code freeze, and a dependency of a number of other
patches.
Catversion bump, for obvious reasons.
Author: Andres Freund, with contributions by John Naylor
Discussion: https://postgr.es/m/20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de
2018-11-21 00:36:57 +01:00
|
|
|
tupdesc = CreateTemplateTupleDesc(12);
|
2016-03-05 20:10:19 +01:00
|
|
|
TupleDescInitEntry(tupdesc, (AttrNumber) 1, "max_data_alignment",
|
|
|
|
INT4OID, -1, 0);
|
|
|
|
TupleDescInitEntry(tupdesc, (AttrNumber) 2, "database_block_size",
|
|
|
|
INT4OID, -1, 0);
|
|
|
|
TupleDescInitEntry(tupdesc, (AttrNumber) 3, "blocks_per_segment",
|
|
|
|
INT4OID, -1, 0);
|
|
|
|
TupleDescInitEntry(tupdesc, (AttrNumber) 4, "wal_block_size",
|
|
|
|
INT4OID, -1, 0);
|
|
|
|
TupleDescInitEntry(tupdesc, (AttrNumber) 5, "bytes_per_wal_segment",
|
|
|
|
INT4OID, -1, 0);
|
|
|
|
TupleDescInitEntry(tupdesc, (AttrNumber) 6, "max_identifier_length",
|
|
|
|
INT4OID, -1, 0);
|
|
|
|
TupleDescInitEntry(tupdesc, (AttrNumber) 7, "max_index_columns",
|
|
|
|
INT4OID, -1, 0);
|
|
|
|
TupleDescInitEntry(tupdesc, (AttrNumber) 8, "max_toast_chunk_size",
|
|
|
|
INT4OID, -1, 0);
|
|
|
|
TupleDescInitEntry(tupdesc, (AttrNumber) 9, "large_object_chunk_size",
|
|
|
|
INT4OID, -1, 0);
|
2019-11-21 18:00:07 +01:00
|
|
|
TupleDescInitEntry(tupdesc, (AttrNumber) 10, "float8_pass_by_value",
|
2016-03-05 20:10:19 +01:00
|
|
|
BOOLOID, -1, 0);
|
2019-11-21 18:00:07 +01:00
|
|
|
TupleDescInitEntry(tupdesc, (AttrNumber) 11, "data_page_checksum_version",
|
2016-03-05 20:10:19 +01:00
|
|
|
INT4OID, -1, 0);
|
|
|
|
tupdesc = BlessTupleDesc(tupdesc);
|
|
|
|
|
|
|
|
/* read the control file */
|
Unified logging system for command-line programs
This unifies the various ad hoc logging (message printing, error
printing) systems used throughout the command-line programs.
Features:
- Program name is automatically prefixed.
- Message string does not end with newline. This removes a common
source of inconsistencies and omissions.
- Additionally, a final newline is automatically stripped, simplifying
use of PQerrorMessage() etc., another common source of mistakes.
- I converted error message strings to use %m where possible.
- As a result of the above several points, more translatable message
strings can be shared between different components and between
frontends and backend, without gratuitous punctuation or whitespace
differences.
- There is support for setting a "log level". This is not meant to be
user-facing, but can be used internally to implement debug or
verbose modes.
- Lazy argument evaluation, so no significant overhead if logging at
some level is disabled.
- Some color in the messages, similar to gcc and clang. Set
PG_COLOR=auto to try it out. Some colors are predefined, but can be
customized by setting PG_COLORS.
- Common files (common/, fe_utils/, etc.) can handle logging much more
simply by just using one API without worrying too much about the
context of the calling program, requiring callbacks, or having to
pass "progname" around everywhere.
- Some programs called setvbuf() to make sure that stderr is
unbuffered, even on Windows. But not all programs did that. This
is now done centrally.
Soft goals:
- Reduces vertical space use and visual complexity of error reporting
in the source code.
- Encourages more deliberate classification of messages. For example,
in some cases it wasn't clear without analyzing the surrounding code
whether a message was meant as an error or just an info.
- Concepts and terms are vaguely aligned with popular logging
frameworks such as log4j and Python logging.
This is all just about printing stuff out. Nothing affects program
flow (e.g., fatal exits). The uses are just too varied to do that.
Some existing code had wrappers that do some kind of print-and-exit,
and I adapted those.
I tried to keep the output mostly the same, but there is a lot of
historical baggage to unwind and special cases to consider, and I
might not always have succeeded. One significant change is that
pg_rewind used to write all error messages to stdout. That is now
changed to stderr.
Reviewed-by: Donald Dong <xdong@csumb.edu>
Reviewed-by: Arthur Zakirov <a.zakirov@postgrespro.ru>
Discussion: https://www.postgresql.org/message-id/flat/6a609b43-4f57-7348-6480-bd022f924310@2ndquadrant.com
2019-04-01 14:24:37 +02:00
|
|
|
ControlFile = get_controlfile(DataDir, &crc_ok);
|
2016-09-28 18:00:00 +02:00
|
|
|
if (!crc_ok)
|
2016-07-26 17:23:43 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errmsg("calculated CRC checksum does not match value stored in file")));
|
2016-03-05 20:10:19 +01:00
|
|
|
|
|
|
|
values[0] = Int32GetDatum(ControlFile->maxAlign);
|
|
|
|
nulls[0] = false;
|
|
|
|
|
|
|
|
values[1] = Int32GetDatum(ControlFile->blcksz);
|
|
|
|
nulls[1] = false;
|
|
|
|
|
|
|
|
values[2] = Int32GetDatum(ControlFile->relseg_size);
|
|
|
|
nulls[2] = false;
|
|
|
|
|
|
|
|
values[3] = Int32GetDatum(ControlFile->xlog_blcksz);
|
|
|
|
nulls[3] = false;
|
|
|
|
|
|
|
|
values[4] = Int32GetDatum(ControlFile->xlog_seg_size);
|
|
|
|
nulls[4] = false;
|
|
|
|
|
|
|
|
values[5] = Int32GetDatum(ControlFile->nameDataLen);
|
|
|
|
nulls[5] = false;
|
|
|
|
|
|
|
|
values[6] = Int32GetDatum(ControlFile->indexMaxKeys);
|
|
|
|
nulls[6] = false;
|
|
|
|
|
|
|
|
values[7] = Int32GetDatum(ControlFile->toast_max_chunk_size);
|
|
|
|
nulls[7] = false;
|
|
|
|
|
|
|
|
values[8] = Int32GetDatum(ControlFile->loblksize);
|
|
|
|
nulls[8] = false;
|
|
|
|
|
2019-11-21 18:00:07 +01:00
|
|
|
values[9] = BoolGetDatum(ControlFile->float8ByVal);
|
2016-03-05 20:10:19 +01:00
|
|
|
nulls[9] = false;
|
|
|
|
|
2019-11-21 18:00:07 +01:00
|
|
|
values[10] = Int32GetDatum(ControlFile->data_checksum_version);
|
2016-03-05 20:10:19 +01:00
|
|
|
nulls[10] = false;
|
|
|
|
|
|
|
|
htup = heap_form_tuple(tupdesc, values, nulls);
|
|
|
|
|
|
|
|
PG_RETURN_DATUM(HeapTupleGetDatum(htup));
|
|
|
|
}
|