User visible catalogs and views#
Catalogs and views are presented here in alphabetical order.
bdr.camo_decision_journal#
A persistent journal of decisions resolved by a CAMO partner node after
a failover, in case bdr.logical_transaction_status was invoked.
Unlike bdr.node_pre_commit , this doesn’t cover transactions
processed under normal operational conditions (i.e., both nodes of a
CAMO pair are running and connected). Entries in this journal aren’t
ever cleaned up automatically. This is a diagnostic tool that the system
doesn’t depend on.
bdr.camo_decision_journal columns#
bdr.commit_scopes#
Catalog storing all possible commit scopes that you can use for
bdr.commit_scope to enable Group Commit.
bdr.commit_scopes columns#
bdr.conflict_history#
This table is the default table where conflicts are logged. The table is
RANGE partitioned on column local_time and is managed by
Autopartition. The default data retention period is 30 days.
Access to this table is possible by any table owner, who can see all conflicts for the tables they own, restricted by row-level security.
For details, see Logging conflicts to a table .
bdr.conflict_history columns#
bdr.conflict_history_summary#
A view containing user-readable details on row conflict.
bdr.conflict_history_summary columns#
bdr.consensus_kv_data#
A persistent storage for the internal Raft-based KV store used by
bdr.consensus_kv_store() and bdr.consensus_kv_fetch()
interfaces.
bdr.consensus_kv_data Columns#
bdr.crdt_handlers#
This table lists merge (“handlers”) functions for all CRDT data types.
bdr.crdt_handlers Columns#
bdr.ddl_replication#
- This view lists DDL replication configuration as set up by current
bdr.ddl_replication columns#
bdr.depend#
This table tracks internal object dependencies inside PGD catalogs.
bdr.global_consensus_journal#
This catalog table logs all the Raft messages that were sent while managing global consensus.
As for the bdr.global_consensus_response_journal catalog, the
payload is stored in a binary encoded format, which can be decoded with
the bdr.decode_message_payload() function. See the bdr.global_consensus_journal_details
view for more details.
bdr.global_consensus_journal columns#
bdr.global_consensus_journal_details#
This view presents Raft messages that were sent and the corresponding
responses, using the bdr.decode_message_payload() function to decode
their payloads.
bdr.global_consensus_journal_details columns#
bdr.global_consensus_response_journal#
This catalog table collects all the responses to the Raft messages that were received while managing global consensus.
As for the bdr.global_consensus_journal catalog, the payload is
stored in a binary-encoded format, which can be decoded with the
bdr.decode_message_payload() function. See the bdr.global_consensus_journal_details view
for more details.
bdr.global_consensus_response_journal columns#
bdr.global_lock#
This catalog table stores the information needed for recovering the global lock state on server restart.
For monitoring usage, the bdr.global_locks view is preferable because the
visible rows in bdr.global_lock don’t necessarily reflect all global
locking activity.
Don’t modify the contents of this table. It is an important PGD catalog.
bdr.global_lock columns#
bdr.global_locks#
A view containing active global locks on this node. The bdr.global_locks view exposes PGD’s shared-memory lock state tracking, giving administrators greater insight into PGD’s global locking activity and progress.
for more information about global locking.
bdr.global_locks columns#
Column details:
relation: For DML locks,relationshows the relation on which the DML lock is acquired. For global advisory locks,relationcolumn actually shows the two 32-bit integers or one 64-bit integer on which the lock is acquired.origin_node_idandorigin_node_name: If these are the same as the local node’s ID and name, then the local node is the initiator of the global DDL lock, i.e., it is the node running the acquiring transaction. If these fields specify a different node, then the local node is instead trying to acquire its local DDL lock to satisfy a global DDL lock request from a remote node.pid: The process ID of the process that requested the global DDL lock, if the local node is the requesting node. Null on other nodes. Query the origin node to determine the locker pid.global_lock_request_time: The timestamp at which the global-lock request initiator started the process of acquiring a global lock. Can be null if unknown on the current node. This time is stamped at the beginning of the DDL lock request and includes the time taken for DDL epoch management and any required flushes of pending-replication queues. Currently only known on origin node.local_lock_request_time: The timestamp at which the local node started trying to acquire the local lock for this global lock. This includes the time taken for the heavyweight session lock acquire but doesn’t include any time taken on DDL epochs or queue flushing. If the lock is reacquired after local node restart, it becomes the node restart time.last_state_change_time: The timestamp at which thebdr.global_locks.acquire_stagefield last changed for this global lock entry.
bdr.group_camo_details#
Uses bdr.run_on_all_nodes to gather CAMO-related information from
all nodes.
bdr.group_camo_details columns#
bdr.group_raft_details#
Uses bdr.run_on_all_nodes to gather Raft Consensus status from all
nodes.
bdr.group_raft_details columns#
bdr.group_replslots_details#
Uses bdr.run_on_all_nodes to gather PGD slot information from all
nodes.
bdr.group_replslots_details columns#
bdr.group_subscription_summary#
Uses bdr.run_on_all_nodes to gather subscription status from all
nodes.
bdr.group_subscription_summary columns#
bdr.group_versions_details#
Uses bdr.run_on_all_nodes to gather PGD information from all nodes.
bdr.group_versions_details columns#
bdr.local_consensus_snapshot#
This catalog table contains consensus snapshots created or received by the local node.
bdr.local_consensus_snapshot columns#
bdr.local_consensus_state#
This catalog table stores the current state of Raft on the local node.
bdr.local_consensus_state columns#
bdr.local_node#
This table identifies the local node in the current database of the current Postgres instance.
bdr.local_node columns#
bdr.local_node_summary#
A view containing the same information as bdr.node_summary (plus
pub_repsets and sub_repsets ), but only for the local node.
bdr.local_sync_status#
Information about status of either subscription or table synchronization process.
bdr.local_sync_status columns#
bdr.node#
This table lists all the PGD nodes in the cluster.
bdr.node columns#
bdr.node_catchup_info#
This catalog table records relevant catchup information on each node, either if it is related to the join or part procedure.
bdr.node_catchup_info columns#
If a node(node_id) needs missing data from a parting node(origin_node_id), it can get it from a node that already has it(node_source_id) by forwarding. The records in this table persists until the node(node_id) is a member of the EDB Postgres Distributed cluster.
bdr.node_catchup_info_details#
A view of bdr.node_catchup_info catalog which shows info in more
friendly way
bdr.node_conflict_resolvers#
Currently configured conflict resolution for all known conflict types.
bdr.node_conflict_resolvers columns#
bdr.node_group#
This catalog table lists all the PGD node groups.
bdr.node_group columns#
bdr.node_group_replication_sets#
A view showing default replication sets create for PGD groups. See also
bdr.replication_sets .
bdr.node_group_replication_sets columns#
bdr.node_local_info#
A catalog table used to store per-node configuration that’s specific to the local node (as opposed to global view of per-node configuration).
bdr.node_local_info columns#
bdr.node_log_config#
A catalog view that stores information on the conflict logging configurations.
bdr.node_log_config columns#
Name |
Description |
|---|---|
log_name |
Name of the logging configuration |
log_to_file |
Whether it logs to the server log file |
log_to_table |
Whether it logs to a table, and which table is the target |
log_conflict_type |
Which conflict types it logs, if NULL means all |
log_conflict_res |
Which conflict resolutions it logs, if NULL means all |
bdr.node_peer_progress#
Catalog used to keep track of every node’s progress in the replication
stream. Every node in the cluster regularly broadcasts its progress
every bdr.replay_progress_frequency milliseconds to all other nodes
(default is 60000 ms, i.e., 1 minute). Expect N * (N-1) rows in this
relation.
You might be more interested in the bdr.node_slots view for
monitoring purposes. See also Monitoring .
bdr.node_peer_progress columns#
bdr.node_replication_rates#
This view contains information about outgoing replication activity from a given node.
bdr.node_replication_rates columns#
Note
The replay_lag is set immediately to zero after reconnect. As a workaround, use replay_lag_bytes , replay_lag_size , or catchup_interval .
bdr.node_slots#
This view contains information about replication slots used in the current database by PGD.
See Monitoring outgoing replication
for guidance on the use and interpretation of this view’s fields.
bdr.node_slots columns#
Note
The replay_lag is set immediately to zero after reconnect. As a workaround, use replay_lag_bytes or replay_lag_size .
bdr.node_summary#
This view contains summary information about all PGD nodes known to the local node.
bdr.node_summary columns#
bdr.queue#
This table stores the historical record of replicated DDL statements.
bdr.queue columns#
bdr.replication_set#
A table that stores replication set configuration. For user queries, we
recommend instead checking the bdr.replication_sets view.
bdr.replication_set columns#
bdr.replication_set_table#
A table that stores replication set table membership. For user queries,
we recommend instead checking the bdr.tables view.
bdr.replication_set_table columns#
bdr.replication_set_ddl#
A table that stores replication set ddl replication filters. For user
queries, we recommend instead checking the bdr.ddl_replication view.
bdr.replication_set_ddl Columns#
bdr.replication_sets#
A view showing replication sets defined in the PGD group, even if they aren’t currently used by any node.
bdr.replication_sets columns#
bdr.schema_changes#
A simple view to show all the changes to schemas win PGD.
bdr.schema_changes columns#
bdr.sequence_alloc#
A view to see the allocation details for galloc sequences.
bdr.sequence_alloc columns#
bdr.sequences#
This view lists all sequences with their kind, excluding sequences for internal PGD bookkeeping.
bdr.sequences columns#
bdr.stat_activity#
Dynamic activity for each backend or worker process.
This contains the same information as pg_stat_activity , except
wait_event is set correctly when the wait relates to PGD.
bdr.stat_relation#
Apply statistics for each relation. Contains data only if the tracking is enabled and something was replicated for a given relation.
bdr.stat_relation columns#
bdr.stat_subscription#
Apply statistics for each subscription. Contains data only if the tracking is enabled.
bdr.stat_subscription columns#
bdr.subscription#
This catalog table lists all the subscriptions owned by the local PGD node and their modes.
bdr.subscription columns#
bdr.subscription_summary#
This view contains summary information about all PGD subscriptions that the local node has to other nodes.
bdr.subscription_summary columns#
bdr.tables#
This view lists information about table membership in replication sets. If a table exists in multiple replication sets, it appears multiple times in this table.
bdr.tables columns#
(*) These columns are reserved for future use and should currently be NULL
bdr.taskmgr_work_queue#
Contains work items created and processed by task manager. The work items are created on only one node and processed on different nodes.
bdr.taskmgr_work_queue columns#
bdr.taskmgr_workitem_status#
The status of the work items that is updated locally on each node.
bdr.taskmgr_workitem_status columns#
bdr.taskmgr_local_work_queue#
Contains work items created and processed by the task manager. This is
similar to bdr.taskmgr_work_queue , except that these work items are
for locally managed tables. Each node creates and processes its own
local work items, independent of other nodes in the cluster.
bdr.taskmgr_local_work_queue columns#
bdr.taskmgr_local_workitem_status#
The status of the work items for locally managed tables.
bdr.taskmgr_local_workitem_status columns#
bdr.trigger#
In this view, you can see all the stream triggers created. Often
triggers here are created from bdr.create_conflict_trigger .
bdr.trigger columns#
bdr.triggers#
An expanded view of bdr.trigger with columns that are easier to
read.
bdr.workers#
Information about running PGD worker processes.
This can be joined with bdr.stat_activity using pid to get even more
insight into the state of PGD workers.
bdr.workers Columns#
bdr.writers#
Specific information about PGD writer processes.
bdr.writers columns#
bdr.worker_tasks#
The bdr.worker_tasks view shows PGD’s current worker launch rate
limiting state as well as some basic statistics on background worker
launch and registration activity.
Unlike the other views listed here, it isn’t specific to the current database and PGD node. State for all PGD nodes on the current PostgreSQL instance is shown. Join on the current database to filter it.
bdr.worker_tasks doesn’t track walsenders and output plugins.