2012-11-28 16:35:01 +01:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
|
|
|
* xlogdesc.c
|
2013-05-29 22:58:43 +02:00
|
|
|
* rmgr descriptor routines for access/transam/xlog.c
|
2012-11-28 16:35:01 +01:00
|
|
|
*
|
2015-01-06 17:43:47 +01:00
|
|
|
* Portions Copyright (c) 1996-2015, PostgreSQL Global Development Group
|
2012-11-28 16:35:01 +01:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
|
|
|
*
|
|
|
|
*
|
|
|
|
* IDENTIFICATION
|
2013-05-29 22:58:43 +02:00
|
|
|
* src/backend/access/rmgrdesc/xlogdesc.c
|
2012-11-28 16:35:01 +01:00
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
#include "postgres.h"
|
|
|
|
|
2012-12-13 13:59:13 +01:00
|
|
|
#include "access/xlog.h"
|
2012-11-28 16:35:01 +01:00
|
|
|
#include "access/xlog_internal.h"
|
|
|
|
#include "catalog/pg_control.h"
|
|
|
|
#include "utils/guc.h"
|
2013-01-29 01:06:15 +01:00
|
|
|
#include "utils/timestamp.h"
|
2012-11-28 16:35:01 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* GUC support
|
|
|
|
*/
|
|
|
|
const struct config_enum_entry wal_level_options[] = {
|
|
|
|
{"minimal", WAL_LEVEL_MINIMAL, false},
|
|
|
|
{"archive", WAL_LEVEL_ARCHIVE, false},
|
|
|
|
{"hot_standby", WAL_LEVEL_HOT_STANDBY, false},
|
Add new wal_level, logical, sufficient for logical decoding.
When wal_level=logical, we'll log columns from the old tuple as
configured by the REPLICA IDENTITY facility added in commit
07cacba983ef79be4a84fcd0e0ca3b5fcb85dd65. This makes it possible
a properly-configured logical replication solution to correctly
follow table updates even if they change the chosen key columns,
or, with REPLICA IDENTITY FULL, even if the table has no key at
all. Note that updates which do not modify the replica identity
column won't log anything extra, making the choice of a good key
(i.e. one that will rarely be changed) important to performance
when wal_level=logical is configured.
Each insert, update, or delete to a catalog table will also log
the CMIN and/or CMAX values of stamped by the current transaction.
This is necessary because logical decoding will require access to
historical snapshots of the catalog in order to decode some data
types, and the CMIN/CMAX values that we may need in order to judge
row visibility may have been overwritten by the time we need them.
Andres Freund, reviewed in various versions by myself, Heikki
Linnakangas, KONDO Mitsumasa, and many others.
2013-12-11 00:33:45 +01:00
|
|
|
{"logical", WAL_LEVEL_LOGICAL, false},
|
2012-11-28 16:35:01 +01:00
|
|
|
{NULL, 0, false}
|
|
|
|
};
|
|
|
|
|
|
|
|
void
|
Revamp the WAL record format.
Each WAL record now carries information about the modified relation and
block(s) in a standardized format. That makes it easier to write tools that
need that information, like pg_rewind, prefetching the blocks to speed up
recovery, etc.
There's a whole new API for building WAL records, replacing the XLogRecData
chains used previously. The new API consists of XLogRegister* functions,
which are called for each buffer and chunk of data that is added to the
record. The new API also gives more control over when a full-page image is
written, by passing flags to the XLogRegisterBuffer function.
This also simplifies the XLogReadBufferForRedo() calls. The function can dig
the relation and block number from the WAL record, so they no longer need to
be passed as arguments.
For the convenience of redo routines, XLogReader now disects each WAL record
after reading it, copying the main data part and the per-block data into
MAXALIGNed buffers. The data chunks are not aligned within the WAL record,
but the redo routines can assume that the pointers returned by XLogRecGet*
functions are. Redo routines are now passed the XLogReaderState, which
contains the record in the already-disected format, instead of the plain
XLogRecord.
The new record format also makes the fixed size XLogRecord header smaller,
by removing the xl_len field. The length of the "main data" portion is now
stored at the end of the WAL record, and there's a separate header after
XLogRecord for it. The alignment padding at the end of XLogRecord is also
removed. This compansates for the fact that the new format would otherwise
be more bulky than the old format.
Reviewed by Andres Freund, Amit Kapila, Michael Paquier, Alvaro Herrera,
Fujii Masao.
2014-11-20 16:56:26 +01:00
|
|
|
xlog_desc(StringInfo buf, XLogReaderState *record)
|
2012-11-28 16:35:01 +01:00
|
|
|
{
|
2014-06-14 09:46:48 +02:00
|
|
|
char *rec = XLogRecGetData(record);
|
Revamp the WAL record format.
Each WAL record now carries information about the modified relation and
block(s) in a standardized format. That makes it easier to write tools that
need that information, like pg_rewind, prefetching the blocks to speed up
recovery, etc.
There's a whole new API for building WAL records, replacing the XLogRecData
chains used previously. The new API consists of XLogRegister* functions,
which are called for each buffer and chunk of data that is added to the
record. The new API also gives more control over when a full-page image is
written, by passing flags to the XLogRegisterBuffer function.
This also simplifies the XLogReadBufferForRedo() calls. The function can dig
the relation and block number from the WAL record, so they no longer need to
be passed as arguments.
For the convenience of redo routines, XLogReader now disects each WAL record
after reading it, copying the main data part and the per-block data into
MAXALIGNed buffers. The data chunks are not aligned within the WAL record,
but the redo routines can assume that the pointers returned by XLogRecGet*
functions are. Redo routines are now passed the XLogReaderState, which
contains the record in the already-disected format, instead of the plain
XLogRecord.
The new record format also makes the fixed size XLogRecord header smaller,
by removing the xl_len field. The length of the "main data" portion is now
stored at the end of the WAL record, and there's a separate header after
XLogRecord for it. The alignment padding at the end of XLogRecord is also
removed. This compansates for the fact that the new format would otherwise
be more bulky than the old format.
Reviewed by Andres Freund, Amit Kapila, Michael Paquier, Alvaro Herrera,
Fujii Masao.
2014-11-20 16:56:26 +01:00
|
|
|
uint8 info = XLogRecGetInfo(record) & ~XLR_INFO_MASK;
|
2012-11-28 16:35:01 +01:00
|
|
|
|
|
|
|
if (info == XLOG_CHECKPOINT_SHUTDOWN ||
|
|
|
|
info == XLOG_CHECKPOINT_ONLINE)
|
|
|
|
{
|
|
|
|
CheckPoint *checkpoint = (CheckPoint *) rec;
|
|
|
|
|
2014-09-19 15:17:12 +02:00
|
|
|
appendStringInfo(buf, "redo %X/%X; "
|
2013-02-11 17:13:09 +01:00
|
|
|
"tli %u; prev tli %u; fpw %s; xid %u/%u; oid %u; multi %u; offset %u; "
|
Improve concurrency of foreign key locking
This patch introduces two additional lock modes for tuples: "SELECT FOR
KEY SHARE" and "SELECT FOR NO KEY UPDATE". These don't block each
other, in contrast with already existing "SELECT FOR SHARE" and "SELECT
FOR UPDATE". UPDATE commands that do not modify the values stored in
the columns that are part of the key of the tuple now grab a SELECT FOR
NO KEY UPDATE lock on the tuple, allowing them to proceed concurrently
with tuple locks of the FOR KEY SHARE variety.
Foreign key triggers now use FOR KEY SHARE instead of FOR SHARE; this
means the concurrency improvement applies to them, which is the whole
point of this patch.
The added tuple lock semantics require some rejiggering of the multixact
module, so that the locking level that each transaction is holding can
be stored alongside its Xid. Also, multixacts now need to persist
across server restarts and crashes, because they can now represent not
only tuple locks, but also tuple updates. This means we need more
careful tracking of lifetime of pg_multixact SLRU files; since they now
persist longer, we require more infrastructure to figure out when they
can be removed. pg_upgrade also needs to be careful to copy
pg_multixact files over from the old server to the new, or at least part
of multixact.c state, depending on the versions of the old and new
servers.
Tuple time qualification rules (HeapTupleSatisfies routines) need to be
careful not to consider tuples with the "is multi" infomask bit set as
being only locked; they might need to look up MultiXact values (i.e.
possibly do pg_multixact I/O) to find out the Xid that updated a tuple,
whereas they previously were assured to only use information readily
available from the tuple header. This is considered acceptable, because
the extra I/O would involve cases that would previously cause some
commands to block waiting for concurrent transactions to finish.
Another important change is the fact that locking tuples that have
previously been updated causes the future versions to be marked as
locked, too; this is essential for correctness of foreign key checks.
This causes additional WAL-logging, also (there was previously a single
WAL record for a locked tuple; now there are as many as updated copies
of the tuple there exist.)
With all this in place, contention related to tuples being checked by
foreign key rules should be much reduced.
As a bonus, the old behavior that a subtransaction grabbing a stronger
tuple lock than the parent (sub)transaction held on a given tuple and
later aborting caused the weaker lock to be lost, has been fixed.
Many new spec files were added for isolation tester framework, to ensure
overall behavior is sane. There's probably room for several more tests.
There were several reviewers of this patch; in particular, Noah Misch
and Andres Freund spent considerable time in it. Original idea for the
patch came from Simon Riggs, after a problem report by Joel Jacobson.
Most code is from me, with contributions from Marti Raudsepp, Alexander
Shulgin, Noah Misch and Andres Freund.
This patch was discussed in several pgsql-hackers threads; the most
important start at the following message-ids:
AANLkTimo9XVcEzfiBR-ut3KVNDkjm2Vxh+t8kAmWjPuv@mail.gmail.com
1290721684-sup-3951@alvh.no-ip.org
1294953201-sup-2099@alvh.no-ip.org
1320343602-sup-2290@alvh.no-ip.org
1339690386-sup-8927@alvh.no-ip.org
4FE5FF020200002500048A3D@gw.wicourts.gov
4FEAB90A0200002500048B7D@gw.wicourts.gov
2013-01-23 16:04:59 +01:00
|
|
|
"oldest xid %u in DB %u; oldest multi %u in DB %u; "
|
Keep track of transaction commit timestamps
Transactions can now set their commit timestamp directly as they commit,
or an external transaction commit timestamp can be fed from an outside
system using the new function TransactionTreeSetCommitTsData(). This
data is crash-safe, and truncated at Xid freeze point, same as pg_clog.
This module is disabled by default because it causes a performance hit,
but can be enabled in postgresql.conf requiring only a server restart.
A new test in src/test/modules is included.
Catalog version bumped due to the new subdirectory within PGDATA and a
couple of new SQL functions.
Authors: Álvaro Herrera and Petr Jelínek
Reviewed to varying degrees by Michael Paquier, Andres Freund, Robert
Haas, Amit Kapila, Fujii Masao, Jaime Casanova, Simon Riggs, Steven
Singer, Peter Eisentraut
2014-12-03 15:53:02 +01:00
|
|
|
"oldest/newest commit timestamp xid: %u/%u; "
|
Improve concurrency of foreign key locking
This patch introduces two additional lock modes for tuples: "SELECT FOR
KEY SHARE" and "SELECT FOR NO KEY UPDATE". These don't block each
other, in contrast with already existing "SELECT FOR SHARE" and "SELECT
FOR UPDATE". UPDATE commands that do not modify the values stored in
the columns that are part of the key of the tuple now grab a SELECT FOR
NO KEY UPDATE lock on the tuple, allowing them to proceed concurrently
with tuple locks of the FOR KEY SHARE variety.
Foreign key triggers now use FOR KEY SHARE instead of FOR SHARE; this
means the concurrency improvement applies to them, which is the whole
point of this patch.
The added tuple lock semantics require some rejiggering of the multixact
module, so that the locking level that each transaction is holding can
be stored alongside its Xid. Also, multixacts now need to persist
across server restarts and crashes, because they can now represent not
only tuple locks, but also tuple updates. This means we need more
careful tracking of lifetime of pg_multixact SLRU files; since they now
persist longer, we require more infrastructure to figure out when they
can be removed. pg_upgrade also needs to be careful to copy
pg_multixact files over from the old server to the new, or at least part
of multixact.c state, depending on the versions of the old and new
servers.
Tuple time qualification rules (HeapTupleSatisfies routines) need to be
careful not to consider tuples with the "is multi" infomask bit set as
being only locked; they might need to look up MultiXact values (i.e.
possibly do pg_multixact I/O) to find out the Xid that updated a tuple,
whereas they previously were assured to only use information readily
available from the tuple header. This is considered acceptable, because
the extra I/O would involve cases that would previously cause some
commands to block waiting for concurrent transactions to finish.
Another important change is the fact that locking tuples that have
previously been updated causes the future versions to be marked as
locked, too; this is essential for correctness of foreign key checks.
This causes additional WAL-logging, also (there was previously a single
WAL record for a locked tuple; now there are as many as updated copies
of the tuple there exist.)
With all this in place, contention related to tuples being checked by
foreign key rules should be much reduced.
As a bonus, the old behavior that a subtransaction grabbing a stronger
tuple lock than the parent (sub)transaction held on a given tuple and
later aborting caused the weaker lock to be lost, has been fixed.
Many new spec files were added for isolation tester framework, to ensure
overall behavior is sane. There's probably room for several more tests.
There were several reviewers of this patch; in particular, Noah Misch
and Andres Freund spent considerable time in it. Original idea for the
patch came from Simon Riggs, after a problem report by Joel Jacobson.
Most code is from me, with contributions from Marti Raudsepp, Alexander
Shulgin, Noah Misch and Andres Freund.
This patch was discussed in several pgsql-hackers threads; the most
important start at the following message-ids:
AANLkTimo9XVcEzfiBR-ut3KVNDkjm2Vxh+t8kAmWjPuv@mail.gmail.com
1290721684-sup-3951@alvh.no-ip.org
1294953201-sup-2099@alvh.no-ip.org
1320343602-sup-2290@alvh.no-ip.org
1339690386-sup-8927@alvh.no-ip.org
4FE5FF020200002500048A3D@gw.wicourts.gov
4FEAB90A0200002500048B7D@gw.wicourts.gov
2013-01-23 16:04:59 +01:00
|
|
|
"oldest running xid %u; %s",
|
2013-05-29 22:58:43 +02:00
|
|
|
(uint32) (checkpoint->redo >> 32), (uint32) checkpoint->redo,
|
2012-11-28 16:35:01 +01:00
|
|
|
checkpoint->ThisTimeLineID,
|
2013-02-11 17:13:09 +01:00
|
|
|
checkpoint->PrevTimeLineID,
|
2012-11-28 16:35:01 +01:00
|
|
|
checkpoint->fullPageWrites ? "true" : "false",
|
|
|
|
checkpoint->nextXidEpoch, checkpoint->nextXid,
|
|
|
|
checkpoint->nextOid,
|
|
|
|
checkpoint->nextMulti,
|
|
|
|
checkpoint->nextMultiOffset,
|
|
|
|
checkpoint->oldestXid,
|
|
|
|
checkpoint->oldestXidDB,
|
Improve concurrency of foreign key locking
This patch introduces two additional lock modes for tuples: "SELECT FOR
KEY SHARE" and "SELECT FOR NO KEY UPDATE". These don't block each
other, in contrast with already existing "SELECT FOR SHARE" and "SELECT
FOR UPDATE". UPDATE commands that do not modify the values stored in
the columns that are part of the key of the tuple now grab a SELECT FOR
NO KEY UPDATE lock on the tuple, allowing them to proceed concurrently
with tuple locks of the FOR KEY SHARE variety.
Foreign key triggers now use FOR KEY SHARE instead of FOR SHARE; this
means the concurrency improvement applies to them, which is the whole
point of this patch.
The added tuple lock semantics require some rejiggering of the multixact
module, so that the locking level that each transaction is holding can
be stored alongside its Xid. Also, multixacts now need to persist
across server restarts and crashes, because they can now represent not
only tuple locks, but also tuple updates. This means we need more
careful tracking of lifetime of pg_multixact SLRU files; since they now
persist longer, we require more infrastructure to figure out when they
can be removed. pg_upgrade also needs to be careful to copy
pg_multixact files over from the old server to the new, or at least part
of multixact.c state, depending on the versions of the old and new
servers.
Tuple time qualification rules (HeapTupleSatisfies routines) need to be
careful not to consider tuples with the "is multi" infomask bit set as
being only locked; they might need to look up MultiXact values (i.e.
possibly do pg_multixact I/O) to find out the Xid that updated a tuple,
whereas they previously were assured to only use information readily
available from the tuple header. This is considered acceptable, because
the extra I/O would involve cases that would previously cause some
commands to block waiting for concurrent transactions to finish.
Another important change is the fact that locking tuples that have
previously been updated causes the future versions to be marked as
locked, too; this is essential for correctness of foreign key checks.
This causes additional WAL-logging, also (there was previously a single
WAL record for a locked tuple; now there are as many as updated copies
of the tuple there exist.)
With all this in place, contention related to tuples being checked by
foreign key rules should be much reduced.
As a bonus, the old behavior that a subtransaction grabbing a stronger
tuple lock than the parent (sub)transaction held on a given tuple and
later aborting caused the weaker lock to be lost, has been fixed.
Many new spec files were added for isolation tester framework, to ensure
overall behavior is sane. There's probably room for several more tests.
There were several reviewers of this patch; in particular, Noah Misch
and Andres Freund spent considerable time in it. Original idea for the
patch came from Simon Riggs, after a problem report by Joel Jacobson.
Most code is from me, with contributions from Marti Raudsepp, Alexander
Shulgin, Noah Misch and Andres Freund.
This patch was discussed in several pgsql-hackers threads; the most
important start at the following message-ids:
AANLkTimo9XVcEzfiBR-ut3KVNDkjm2Vxh+t8kAmWjPuv@mail.gmail.com
1290721684-sup-3951@alvh.no-ip.org
1294953201-sup-2099@alvh.no-ip.org
1320343602-sup-2290@alvh.no-ip.org
1339690386-sup-8927@alvh.no-ip.org
4FE5FF020200002500048A3D@gw.wicourts.gov
4FEAB90A0200002500048B7D@gw.wicourts.gov
2013-01-23 16:04:59 +01:00
|
|
|
checkpoint->oldestMulti,
|
|
|
|
checkpoint->oldestMultiDB,
|
2015-12-28 21:34:11 +01:00
|
|
|
checkpoint->oldestCommitTsXid,
|
|
|
|
checkpoint->newestCommitTsXid,
|
2012-11-28 16:35:01 +01:00
|
|
|
checkpoint->oldestActiveXid,
|
|
|
|
(info == XLOG_CHECKPOINT_SHUTDOWN) ? "shutdown" : "online");
|
|
|
|
}
|
|
|
|
else if (info == XLOG_NEXTOID)
|
|
|
|
{
|
|
|
|
Oid nextOid;
|
|
|
|
|
|
|
|
memcpy(&nextOid, rec, sizeof(Oid));
|
2014-09-19 15:17:12 +02:00
|
|
|
appendStringInfo(buf, "%u", nextOid);
|
2012-11-28 16:35:01 +01:00
|
|
|
}
|
|
|
|
else if (info == XLOG_RESTORE_POINT)
|
|
|
|
{
|
|
|
|
xl_restore_point *xlrec = (xl_restore_point *) rec;
|
|
|
|
|
2015-05-12 02:38:55 +02:00
|
|
|
appendStringInfoString(buf, xlrec->rp_name);
|
2012-11-28 16:35:01 +01:00
|
|
|
}
|
2014-11-24 09:43:32 +01:00
|
|
|
else if (info == XLOG_FPI || info == XLOG_FPI_FOR_HINT)
|
2013-03-22 14:54:07 +01:00
|
|
|
{
|
Revamp the WAL record format.
Each WAL record now carries information about the modified relation and
block(s) in a standardized format. That makes it easier to write tools that
need that information, like pg_rewind, prefetching the blocks to speed up
recovery, etc.
There's a whole new API for building WAL records, replacing the XLogRecData
chains used previously. The new API consists of XLogRegister* functions,
which are called for each buffer and chunk of data that is added to the
record. The new API also gives more control over when a full-page image is
written, by passing flags to the XLogRegisterBuffer function.
This also simplifies the XLogReadBufferForRedo() calls. The function can dig
the relation and block number from the WAL record, so they no longer need to
be passed as arguments.
For the convenience of redo routines, XLogReader now disects each WAL record
after reading it, copying the main data part and the per-block data into
MAXALIGNed buffers. The data chunks are not aligned within the WAL record,
but the redo routines can assume that the pointers returned by XLogRecGet*
functions are. Redo routines are now passed the XLogReaderState, which
contains the record in the already-disected format, instead of the plain
XLogRecord.
The new record format also makes the fixed size XLogRecord header smaller,
by removing the xl_len field. The length of the "main data" portion is now
stored at the end of the WAL record, and there's a separate header after
XLogRecord for it. The alignment padding at the end of XLogRecord is also
removed. This compansates for the fact that the new format would otherwise
be more bulky than the old format.
Reviewed by Andres Freund, Amit Kapila, Michael Paquier, Alvaro Herrera,
Fujii Masao.
2014-11-20 16:56:26 +01:00
|
|
|
/* no further information to print */
|
2013-03-22 14:54:07 +01:00
|
|
|
}
|
2012-11-28 16:35:01 +01:00
|
|
|
else if (info == XLOG_BACKUP_END)
|
|
|
|
{
|
|
|
|
XLogRecPtr startpoint;
|
|
|
|
|
|
|
|
memcpy(&startpoint, rec, sizeof(XLogRecPtr));
|
2014-09-19 15:17:12 +02:00
|
|
|
appendStringInfo(buf, "%X/%X",
|
2012-11-28 16:35:01 +01:00
|
|
|
(uint32) (startpoint >> 32), (uint32) startpoint);
|
|
|
|
}
|
|
|
|
else if (info == XLOG_PARAMETER_CHANGE)
|
|
|
|
{
|
|
|
|
xl_parameter_change xlrec;
|
|
|
|
const char *wal_level_str;
|
|
|
|
const struct config_enum_entry *entry;
|
|
|
|
|
|
|
|
memcpy(&xlrec, rec, sizeof(xl_parameter_change));
|
|
|
|
|
|
|
|
/* Find a string representation for wal_level */
|
|
|
|
wal_level_str = "?";
|
|
|
|
for (entry = wal_level_options; entry->name; entry++)
|
|
|
|
{
|
|
|
|
if (entry->val == xlrec.wal_level)
|
|
|
|
{
|
|
|
|
wal_level_str = entry->name;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-12-05 10:58:24 +01:00
|
|
|
appendStringInfo(buf, "max_connections=%d max_worker_processes=%d "
|
|
|
|
"max_prepared_xacts=%d max_locks_per_xact=%d "
|
2014-12-05 11:11:07 +01:00
|
|
|
"wal_level=%s wal_log_hints=%s "
|
2015-09-29 19:40:56 +02:00
|
|
|
"track_commit_timestamp=%s",
|
2012-11-28 16:35:01 +01:00
|
|
|
xlrec.MaxConnections,
|
Add new GUC, max_worker_processes, limiting number of bgworkers.
In 9.3, there's no particular limit on the number of bgworkers;
instead, we just count up the number that are actually registered,
and use that to set MaxBackends. However, that approach causes
problems for Hot Standby, which needs both MaxBackends and the
size of the lock table to be the same on the standby as on the
master, yet it may not be desirable to run the same bgworkers in
both places. 9.3 handles that by failing to notice the problem,
which will probably work fine in nearly all cases anyway, but is
not theoretically sound.
A further problem with simply counting the number of registered
workers is that new workers can't be registered without a
postmaster restart. This is inconvenient for administrators,
since bouncing the postmaster causes an interruption of service.
Moreover, there are a number of applications for background
processes where, by necessity, the background process must be
started on the fly (e.g. parallel query). While this patch
doesn't actually make it possible to register new background
workers after startup time, it's a necessary prerequisite.
Patch by me. Review by Michael Paquier.
2013-07-04 17:24:24 +02:00
|
|
|
xlrec.max_worker_processes,
|
2012-11-28 16:35:01 +01:00
|
|
|
xlrec.max_prepared_xacts,
|
|
|
|
xlrec.max_locks_per_xact,
|
2014-12-05 10:58:24 +01:00
|
|
|
wal_level_str,
|
2014-12-05 11:11:07 +01:00
|
|
|
xlrec.wal_log_hints ? "on" : "off",
|
|
|
|
xlrec.track_commit_timestamp ? "on" : "off");
|
2012-11-28 16:35:01 +01:00
|
|
|
}
|
|
|
|
else if (info == XLOG_FPW_CHANGE)
|
|
|
|
{
|
|
|
|
bool fpw;
|
|
|
|
|
|
|
|
memcpy(&fpw, rec, sizeof(bool));
|
2015-05-12 02:38:55 +02:00
|
|
|
appendStringInfoString(buf, fpw ? "true" : "false");
|
2012-11-28 16:35:01 +01:00
|
|
|
}
|
2013-01-29 01:06:15 +01:00
|
|
|
else if (info == XLOG_END_OF_RECOVERY)
|
|
|
|
{
|
|
|
|
xl_end_of_recovery xlrec;
|
|
|
|
|
|
|
|
memcpy(&xlrec, rec, sizeof(xl_end_of_recovery));
|
2014-09-19 15:17:12 +02:00
|
|
|
appendStringInfo(buf, "tli %u; prev tli %u; time %s",
|
2013-02-11 17:13:09 +01:00
|
|
|
xlrec.ThisTimeLineID, xlrec.PrevTimeLineID,
|
2013-01-29 01:06:15 +01:00
|
|
|
timestamptz_to_str(xlrec.end_time));
|
|
|
|
}
|
2014-09-19 15:17:12 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
const char *
|
|
|
|
xlog_identify(uint8 info)
|
|
|
|
{
|
|
|
|
const char *id = NULL;
|
|
|
|
|
2014-09-22 16:48:14 +02:00
|
|
|
switch (info & ~XLR_INFO_MASK)
|
2014-09-19 15:17:12 +02:00
|
|
|
{
|
|
|
|
case XLOG_CHECKPOINT_SHUTDOWN:
|
|
|
|
id = "CHECKPOINT_SHUTDOWN";
|
|
|
|
break;
|
|
|
|
case XLOG_CHECKPOINT_ONLINE:
|
|
|
|
id = "CHECKPOINT_ONLINE";
|
|
|
|
break;
|
|
|
|
case XLOG_NOOP:
|
|
|
|
id = "NOOP";
|
|
|
|
break;
|
|
|
|
case XLOG_NEXTOID:
|
|
|
|
id = "NEXTOID";
|
|
|
|
break;
|
|
|
|
case XLOG_SWITCH:
|
|
|
|
id = "SWITCH";
|
|
|
|
break;
|
|
|
|
case XLOG_BACKUP_END:
|
|
|
|
id = "BACKUP_END";
|
|
|
|
break;
|
|
|
|
case XLOG_PARAMETER_CHANGE:
|
|
|
|
id = "PARAMETER_CHANGE";
|
|
|
|
break;
|
|
|
|
case XLOG_RESTORE_POINT:
|
|
|
|
id = "RESTORE_POINT";
|
|
|
|
break;
|
|
|
|
case XLOG_FPW_CHANGE:
|
|
|
|
id = "FPW_CHANGE";
|
|
|
|
break;
|
|
|
|
case XLOG_END_OF_RECOVERY:
|
|
|
|
id = "END_OF_RECOVERY";
|
|
|
|
break;
|
|
|
|
case XLOG_FPI:
|
|
|
|
id = "FPI";
|
|
|
|
break;
|
2014-11-24 09:43:32 +01:00
|
|
|
case XLOG_FPI_FOR_HINT:
|
|
|
|
id = "FPI_FOR_HINT";
|
|
|
|
break;
|
2014-09-19 15:17:12 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
return id;
|
2012-11-28 16:35:01 +01:00
|
|
|
}
|