1996-07-09 08:22:35 +02:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
|
|
|
* pg_dump.h
|
2002-05-11 00:36:27 +02:00
|
|
|
* Common header file for the pg_dump utility
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
2024-01-04 02:49:05 +01:00
|
|
|
* Portions Copyright (c) 1996-2024, PostgreSQL Global Development Group
|
2000-01-26 06:58:53 +01:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/bin/pg_dump/pg_dump.h
|
2000-09-15 06:35:16 +02:00
|
|
|
*
|
1996-07-09 08:22:35 +02:00
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
|
1999-10-23 05:13:33 +02:00
|
|
|
#ifndef PG_DUMP_H
|
|
|
|
#define PG_DUMP_H
|
|
|
|
|
2014-10-14 20:00:55 +02:00
|
|
|
#include "pg_backup.h"
|
2003-12-06 04:00:16 +01:00
|
|
|
|
2006-10-10 01:36:59 +02:00
|
|
|
|
2014-10-14 20:00:55 +02:00
|
|
|
#define oidcmp(x,y) ( ((x) < (y) ? -1 : ((x) > (y)) ? 1 : 0) )
|
1999-10-23 05:13:33 +02:00
|
|
|
|
2002-05-11 00:36:27 +02:00
|
|
|
/*
|
2003-12-06 04:00:16 +01:00
|
|
|
* The data structures used to store system catalog information. Every
|
|
|
|
* dumpable object is a subclass of DumpableObject.
|
2002-05-11 00:36:27 +02:00
|
|
|
*
|
|
|
|
* NOTE: the structures described here live for the entire pg_dump run;
|
|
|
|
* and in most cases we make a struct for every object we can find in the
|
|
|
|
* catalogs, not only those we are actually going to dump. Hence, it's
|
|
|
|
* best to store a minimal amount of per-object info in these structs,
|
|
|
|
* and retrieve additional per-object info when and if we dump a specific
|
|
|
|
* object. In particular, try to avoid retrieving expensive-to-compute
|
2003-12-06 04:00:16 +01:00
|
|
|
* information until it's known to be needed. We do, however, have to
|
|
|
|
* store enough info to determine whether an object should be dumped and
|
|
|
|
* what order to dump in.
|
2002-05-11 00:36:27 +02:00
|
|
|
*/
|
|
|
|
|
2003-12-06 04:00:16 +01:00
|
|
|
typedef enum
|
|
|
|
{
|
2004-03-03 22:28:55 +01:00
|
|
|
/* When modifying this enum, update priority tables in pg_dump_sort.c! */
|
2003-12-06 04:00:16 +01:00
|
|
|
DO_NAMESPACE,
|
2011-02-08 22:08:41 +01:00
|
|
|
DO_EXTENSION,
|
2003-12-06 04:00:16 +01:00
|
|
|
DO_TYPE,
|
2006-03-02 02:18:26 +01:00
|
|
|
DO_SHELL_TYPE,
|
2003-12-06 04:00:16 +01:00
|
|
|
DO_FUNC,
|
|
|
|
DO_AGG,
|
|
|
|
DO_OPERATOR,
|
2016-03-24 03:01:35 +01:00
|
|
|
DO_ACCESS_METHOD,
|
2003-12-06 04:00:16 +01:00
|
|
|
DO_OPCLASS,
|
2007-01-23 18:54:50 +01:00
|
|
|
DO_OPFAMILY,
|
Improve pg_dump's dependency-sorting logic to enforce section dump order.
As of 9.2, with the --section option, it is very important that the concept
of "pre data", "data", and "post data" sections of the output be honored
strictly; else a dump divided into separate sectional files might be
unrestorable. However, the dependency-sorting logic knew nothing of
sections and would happily select output orderings that didn't fit that
structure. Doing so was mostly harmless before 9.2, but now we need to be
sure it doesn't do that. To fix, create dummy objects representing the
section boundaries and add dependencies between them and all the normal
objects. (This might sound expensive but it seems to only add a percent or
two to pg_dump's runtime.)
This also fixes a problem introduced in 9.1 by the feature that allows
incomplete GROUP BY lists when a primary key is given in GROUP BY.
That means that views can depend on primary key constraints. Previously,
pg_dump would deal with that by simply emitting the primary key constraint
before the view definition (and hence before the data section of the
output). That's bad enough for simple serial restores, where creating an
index before the data is loaded works, but is undesirable for speed
reasons. But it could lead to outright failure of parallel restores, as
seen in bug #6699 from Joe Van Dyk. That happened because pg_restore would
switch into parallel mode as soon as it reached the constraint, and then
very possibly would try to emit the view definition before the primary key
was committed (as a consequence of another bug that causes the view not to
be correctly marked as depending on the constraint). Adding the section
boundary constraints forces the dependency-sorting code to break the view
into separate table and rule declarations, allowing the rule, and hence the
primary key constraint it depends on, to revert to their intended location
in the post-data section. This also somewhat accidentally works around the
bogus-dependency-marking problem, because the rule will be correctly shown
as depending on the constraint, so parallel pg_restore will now do the
right thing. (We will fix the bogus-dependency problem for real in a
separate patch, but that patch is not easily back-portable to 9.1, so the
fact that this patch is enough to dodge the only known symptom is
fortunate.)
Back-patch to 9.1, except for the hunk that adds verification that the
finished archive TOC list is in correct section order; the place where
it was convenient to add that doesn't exist in 9.1.
2012-06-26 03:19:10 +02:00
|
|
|
DO_COLLATION,
|
2003-12-06 04:00:16 +01:00
|
|
|
DO_CONVERSION,
|
|
|
|
DO_TABLE,
|
2021-01-12 03:09:03 +01:00
|
|
|
DO_TABLE_ATTACH,
|
2003-12-06 04:00:16 +01:00
|
|
|
DO_ATTRDEF,
|
|
|
|
DO_INDEX,
|
Local partitioned indexes
When CREATE INDEX is run on a partitioned table, create catalog entries
for an index on the partitioned table (which is just a placeholder since
the table proper has no data of its own), and recurse to create actual
indexes on the existing partitions; create them in future partitions
also.
As a convenience gadget, if the new index definition matches some
existing index in partitions, these are picked up and used instead of
creating new ones. Whichever way these indexes come about, they become
attached to the index on the parent table and are dropped alongside it,
and cannot be dropped on isolation unless they are detached first.
To support pg_dump'ing these indexes, add commands
CREATE INDEX ON ONLY <table>
(which creates the index on the parent partitioned table, without
recursing) and
ALTER INDEX ATTACH PARTITION
(which is used after the indexes have been created individually on each
partition, to attach them to the parent index). These reconstruct prior
database state exactly.
Reviewed-by: (in alphabetical order) Peter Eisentraut, Robert Haas, Amit
Langote, Jesper Pedersen, Simon Riggs, David Rowley
Discussion: https://postgr.es/m/20171113170646.gzweigyrgg6pwsg4@alvherre.pgsql
2018-01-19 15:49:22 +01:00
|
|
|
DO_INDEX_ATTACH,
|
Implement multivariate n-distinct coefficients
Add support for explicitly declared statistic objects (CREATE
STATISTICS), allowing collection of statistics on more complex
combinations that individual table columns. Companion commands DROP
STATISTICS and ALTER STATISTICS ... OWNER TO / SET SCHEMA / RENAME are
added too. All this DDL has been designed so that more statistic types
can be added later on, such as multivariate most-common-values and
multivariate histograms between columns of a single table, leaving room
for permitting columns on multiple tables, too, as well as expressions.
This commit only adds support for collection of n-distinct coefficient
on user-specified sets of columns in a single table. This is useful to
estimate number of distinct groups in GROUP BY and DISTINCT clauses;
estimation errors there can cause over-allocation of memory in hashed
aggregates, for instance, so it's a worthwhile problem to solve. A new
special pseudo-type pg_ndistinct is used.
(num-distinct estimation was deemed sufficiently useful by itself that
this is worthwhile even if no further statistic types are added
immediately; so much so that another version of essentially the same
functionality was submitted by Kyotaro Horiguchi:
https://postgr.es/m/20150828.173334.114731693.horiguchi.kyotaro@lab.ntt.co.jp
though this commit does not use that code.)
Author: Tomas Vondra. Some code rework by Álvaro.
Reviewed-by: Dean Rasheed, David Rowley, Kyotaro Horiguchi, Jeff Janes,
Ideriha Takeshi
Discussion: https://postgr.es/m/543AFA15.4080608@fuzzy.cz
https://postgr.es/m/20170320190220.ixlaueanxegqd5gr@alvherre.pgsql
2017-03-24 18:06:10 +01:00
|
|
|
DO_STATSEXT,
|
2003-12-06 04:00:16 +01:00
|
|
|
DO_RULE,
|
|
|
|
DO_TRIGGER,
|
|
|
|
DO_CONSTRAINT,
|
|
|
|
DO_FK_CONSTRAINT, /* see note for ConstraintInfo */
|
|
|
|
DO_PROCLANG,
|
|
|
|
DO_CAST,
|
2004-03-03 22:28:55 +01:00
|
|
|
DO_TABLE_DATA,
|
2016-08-23 18:00:00 +02:00
|
|
|
DO_SEQUENCE_SET,
|
2009-01-18 21:44:45 +01:00
|
|
|
DO_DUMMY_TYPE,
|
2007-08-21 03:11:32 +02:00
|
|
|
DO_TSPARSER,
|
|
|
|
DO_TSDICT,
|
|
|
|
DO_TSTEMPLATE,
|
|
|
|
DO_TSCONFIG,
|
2008-12-19 17:25:19 +01:00
|
|
|
DO_FDW,
|
|
|
|
DO_FOREIGN_SERVER,
|
2009-10-05 21:24:49 +02:00
|
|
|
DO_DEFAULT_ACL,
|
2015-04-26 16:33:14 +02:00
|
|
|
DO_TRANSFORM,
|
2022-12-05 08:52:11 +01:00
|
|
|
DO_LARGE_OBJECT,
|
|
|
|
DO_LARGE_OBJECT_DATA,
|
Improve pg_dump's dependency-sorting logic to enforce section dump order.
As of 9.2, with the --section option, it is very important that the concept
of "pre data", "data", and "post data" sections of the output be honored
strictly; else a dump divided into separate sectional files might be
unrestorable. However, the dependency-sorting logic knew nothing of
sections and would happily select output orderings that didn't fit that
structure. Doing so was mostly harmless before 9.2, but now we need to be
sure it doesn't do that. To fix, create dummy objects representing the
section boundaries and add dependencies between them and all the normal
objects. (This might sound expensive but it seems to only add a percent or
two to pg_dump's runtime.)
This also fixes a problem introduced in 9.1 by the feature that allows
incomplete GROUP BY lists when a primary key is given in GROUP BY.
That means that views can depend on primary key constraints. Previously,
pg_dump would deal with that by simply emitting the primary key constraint
before the view definition (and hence before the data section of the
output). That's bad enough for simple serial restores, where creating an
index before the data is loaded works, but is undesirable for speed
reasons. But it could lead to outright failure of parallel restores, as
seen in bug #6699 from Joe Van Dyk. That happened because pg_restore would
switch into parallel mode as soon as it reached the constraint, and then
very possibly would try to emit the view definition before the primary key
was committed (as a consequence of another bug that causes the view not to
be correctly marked as depending on the constraint). Adding the section
boundary constraints forces the dependency-sorting code to break the view
into separate table and rule declarations, allowing the rule, and hence the
primary key constraint it depends on, to revert to their intended location
in the post-data section. This also somewhat accidentally works around the
bogus-dependency-marking problem, because the rule will be correctly shown
as depending on the constraint, so parallel pg_restore will now do the
right thing. (We will fix the bogus-dependency problem for real in a
separate patch, but that patch is not easily back-portable to 9.1, so the
fact that this patch is enough to dodge the only known symptom is
fortunate.)
Back-patch to 9.1, except for the hunk that adds verification that the
finished archive TOC list is in correct section order; the place where
it was convenient to add that doesn't exist in 9.1.
2012-06-26 03:19:10 +02:00
|
|
|
DO_PRE_DATA_BOUNDARY,
|
2012-07-18 16:16:16 +02:00
|
|
|
DO_POST_DATA_BOUNDARY,
|
2013-03-04 01:23:31 +01:00
|
|
|
DO_EVENT_TRIGGER,
|
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
|
|
|
DO_REFRESH_MATVIEW,
|
2017-01-19 18:00:00 +01:00
|
|
|
DO_POLICY,
|
|
|
|
DO_PUBLICATION,
|
|
|
|
DO_PUBLICATION_REL,
|
2021-11-09 04:09:33 +01:00
|
|
|
DO_PUBLICATION_TABLE_IN_SCHEMA,
|
2017-01-19 18:00:00 +01:00
|
|
|
DO_SUBSCRIPTION,
|
Allow upgrades to preserve the full subscription's state.
This feature will allow us to replicate the changes on subscriber nodes
after the upgrade.
Previously, only the subscription metadata information was preserved.
Without the list of relations and their state, it's not possible to
re-enable the subscriptions without missing some records as the list of
relations can only be refreshed after enabling the subscription (and
therefore starting the apply worker). Even if we added a way to refresh
the subscription while enabling a publication, we still wouldn't know
which relations are new on the publication side, and therefore should be
fully synced, and which shouldn't.
To preserve the subscription relations, this patch teaches pg_dump to
restore the content of pg_subscription_rel from the old cluster by using
binary_upgrade_add_sub_rel_state SQL function. This is supported only
in binary upgrade mode.
The subscription's replication origin is needed to ensure that we don't
replicate anything twice.
To preserve the replication origins, this patch teaches pg_dump to update
the replication origin along with creating a subscription by using
binary_upgrade_replorigin_advance SQL function to restore the
underlying replication origin remote LSN. This is supported only in
binary upgrade mode.
pg_upgrade will check that all the subscription relations are in 'i'
(init) or in 'r' (ready) state and will error out if that's not the case,
logging the reason for the failure. This helps to avoid the risk of any
dangling slot or origin after the upgrade.
Author: Vignesh C, Julien Rouhaud, Shlok Kyal
Reviewed-by: Peter Smith, Masahiko Sawada, Michael Paquier, Amit Kapila, Hayato Kuroda
Discussion: https://postgr.es/m/20230217075433.u5mjly4d5cr4hcfe@jrouhaud
2024-01-02 03:38:46 +01:00
|
|
|
DO_SUBSCRIPTION_REL, /* see note for SubRelInfo */
|
2003-12-06 04:00:16 +01:00
|
|
|
} DumpableObjectType;
|
|
|
|
|
2021-12-06 18:25:48 +01:00
|
|
|
/*
|
|
|
|
* DumpComponents is a bitmask of the potentially dumpable components of
|
|
|
|
* a database object: its core definition, plus optional attributes such
|
|
|
|
* as ACL, comments, etc. The NONE and ALL symbols are convenient
|
|
|
|
* shorthands.
|
|
|
|
*/
|
|
|
|
typedef uint32 DumpComponents;
|
2016-04-07 03:45:32 +02:00
|
|
|
#define DUMP_COMPONENT_NONE (0)
|
|
|
|
#define DUMP_COMPONENT_DEFINITION (1 << 0)
|
|
|
|
#define DUMP_COMPONENT_DATA (1 << 1)
|
|
|
|
#define DUMP_COMPONENT_COMMENT (1 << 2)
|
|
|
|
#define DUMP_COMPONENT_SECLABEL (1 << 3)
|
|
|
|
#define DUMP_COMPONENT_ACL (1 << 4)
|
|
|
|
#define DUMP_COMPONENT_POLICY (1 << 5)
|
|
|
|
#define DUMP_COMPONENT_USERMAP (1 << 6)
|
|
|
|
#define DUMP_COMPONENT_ALL (0xFFFF)
|
|
|
|
|
2016-05-06 20:06:50 +02:00
|
|
|
/*
|
|
|
|
* component types which require us to obtain a lock on the table
|
|
|
|
*
|
|
|
|
* Note that some components only require looking at the information
|
|
|
|
* in the pg_catalog tables and, for those components, we do not need
|
|
|
|
* to lock the table. Be careful here though- some components use
|
|
|
|
* server-side functions which pull the latest information from
|
|
|
|
* SysCache and in those cases we *do* need to lock the table.
|
|
|
|
*
|
|
|
|
* We do not need locks for the COMMENT and SECLABEL components as
|
|
|
|
* those simply query their associated tables without using any
|
|
|
|
* server-side functions. We do not need locks for the ACL component
|
|
|
|
* as we pull that information from pg_class without using any
|
|
|
|
* server-side functions that use SysCache. The USERMAP component
|
|
|
|
* is only relevant for FOREIGN SERVERs and not tables, so no sense
|
|
|
|
* locking a table for that either (that can happen if we are going
|
|
|
|
* to dump "ALL" components for a table).
|
|
|
|
*
|
|
|
|
* We DO need locks for DEFINITION, due to various server-side
|
|
|
|
* functions that are used and POLICY due to pg_get_expr(). We set
|
|
|
|
* this up to grab the lock except in the cases we know to be safe.
|
|
|
|
*/
|
|
|
|
#define DUMP_COMPONENTS_REQUIRING_LOCK (\
|
|
|
|
DUMP_COMPONENT_DEFINITION |\
|
|
|
|
DUMP_COMPONENT_DATA |\
|
|
|
|
DUMP_COMPONENT_POLICY)
|
|
|
|
|
2003-12-06 04:00:16 +01:00
|
|
|
typedef struct _dumpableObject
|
|
|
|
{
|
|
|
|
DumpableObjectType objType;
|
|
|
|
CatalogId catId; /* zero if not a cataloged object */
|
|
|
|
DumpId dumpId; /* assigned by AssignDumpId() */
|
2004-03-03 22:28:55 +01:00
|
|
|
char *name; /* object name (should never be NULL) */
|
|
|
|
struct _namespaceInfo *namespace; /* containing namespace, or NULL */
|
2021-12-06 18:25:48 +01:00
|
|
|
DumpComponents dump; /* bitmask of components requested to dump */
|
2016-04-07 03:45:32 +02:00
|
|
|
DumpComponents dump_contains; /* as above, but for contained objects */
|
2021-12-06 18:25:48 +01:00
|
|
|
DumpComponents components; /* bitmask of components available to dump */
|
2011-02-10 01:17:33 +01:00
|
|
|
bool ext_member; /* true if object is member of extension */
|
2020-03-11 20:54:54 +01:00
|
|
|
bool depends_on_ext; /* true if object depends on an extension */
|
2003-12-06 04:00:16 +01:00
|
|
|
DumpId *dependencies; /* dumpIds of objects this one depends on */
|
|
|
|
int nDeps; /* number of valid dependencies */
|
|
|
|
int allocDeps; /* allocated size of dependencies[] */
|
|
|
|
} DumpableObject;
|
|
|
|
|
2021-12-06 18:39:45 +01:00
|
|
|
/*
|
|
|
|
* Object types that have ACLs must store them in a DumpableAcl sub-struct,
|
|
|
|
* which must immediately follow the DumpableObject base struct.
|
|
|
|
*/
|
|
|
|
typedef struct _dumpableAcl
|
|
|
|
{
|
|
|
|
char *acl; /* the object's actual ACL string */
|
|
|
|
char *acldefault; /* default ACL for the object's type & owner */
|
|
|
|
/* these fields come from the object's pg_init_privs entry, if any: */
|
|
|
|
char privtype; /* entry type, 'i' or 'e'; 0 if no entry */
|
|
|
|
char *initprivs; /* the object's initial ACL string, or NULL */
|
|
|
|
} DumpableAcl;
|
|
|
|
|
|
|
|
/* Generic struct that can be used to access any object type having an ACL */
|
|
|
|
typedef struct _dumpableObjectWithAcl
|
|
|
|
{
|
|
|
|
DumpableObject dobj;
|
|
|
|
DumpableAcl dacl;
|
|
|
|
} DumpableObjectWithAcl;
|
|
|
|
|
2002-05-11 00:36:27 +02:00
|
|
|
typedef struct _namespaceInfo
|
|
|
|
{
|
2003-12-06 04:00:16 +01:00
|
|
|
DumpableObject dobj;
|
2021-12-06 18:39:45 +01:00
|
|
|
DumpableAcl dacl;
|
2021-06-29 03:34:55 +02:00
|
|
|
bool create; /* CREATE SCHEMA, or just set owner? */
|
2021-12-31 17:39:26 +01:00
|
|
|
Oid nspowner; /* OID of owner */
|
|
|
|
const char *rolname; /* name of owner */
|
2002-05-11 00:36:27 +02:00
|
|
|
} NamespaceInfo;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2011-02-08 22:08:41 +01:00
|
|
|
typedef struct _extensionInfo
|
|
|
|
{
|
|
|
|
DumpableObject dobj;
|
|
|
|
char *namespace; /* schema containing extension's objects */
|
2011-02-10 01:17:33 +01:00
|
|
|
bool relocatable;
|
|
|
|
char *extversion;
|
2011-02-09 20:05:34 +01:00
|
|
|
char *extconfig; /* info about configuration tables */
|
|
|
|
char *extcondition;
|
2011-02-08 22:08:41 +01:00
|
|
|
} ExtensionInfo;
|
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
typedef struct _typeInfo
|
|
|
|
{
|
2003-12-06 04:00:16 +01:00
|
|
|
DumpableObject dobj;
|
2021-12-06 18:39:45 +01:00
|
|
|
DumpableAcl dacl;
|
2004-08-29 07:07:03 +02:00
|
|
|
|
2004-03-03 22:28:55 +01:00
|
|
|
/*
|
2021-08-31 19:53:33 +02:00
|
|
|
* Note: dobj.name is the raw pg_type.typname entry. ftypname is the
|
|
|
|
* result of format_type(), which will be quoted if needed, and might be
|
|
|
|
* schema-qualified too.
|
2004-03-03 22:28:55 +01:00
|
|
|
*/
|
2021-08-31 19:53:33 +02:00
|
|
|
char *ftypname;
|
2021-12-31 17:39:26 +01:00
|
|
|
const char *rolname;
|
2003-12-06 04:00:16 +01:00
|
|
|
Oid typelem;
|
|
|
|
Oid typrelid;
|
2002-08-15 18:36:08 +02:00
|
|
|
char typrelkind; /* 'r', 'v', 'c', etc */
|
2002-05-11 00:36:27 +02:00
|
|
|
char typtype; /* 'b', 'c', etc */
|
Support arrays of composite types, including the rowtypes of regular tables
and views (but not system catalogs, nor sequences or toast tables). Get rid
of the hardwired convention that a type's array type is named exactly "_type",
instead using a new column pg_type.typarray to provide the linkage. (It still
will be named "_type", though, except in odd corner cases such as
maximum-length type names.)
Along the way, make tracking of owner and schema dependencies for types more
uniform: a type directly created by the user has these dependencies, while a
table rowtype or auto-generated array type does not have them, but depends on
its parent object instead.
David Fetter, Andrew Dunstan, Tom Lane
2007-05-11 19:57:14 +02:00
|
|
|
bool isArray; /* true if auto-generated array type */
|
Multirange datatypes
Multiranges are basically sorted arrays of non-overlapping ranges with
set-theoretic operations defined over them.
Since v14, each range type automatically gets a corresponding multirange
datatype. There are both manual and automatic mechanisms for naming multirange
types. Once can specify multirange type name using multirange_type_name
attribute in CREATE TYPE. Otherwise, a multirange type name is generated
automatically. If the range type name contains "range" then we change that to
"multirange". Otherwise, we add "_multirange" to the end.
Implementation of multiranges comes with a space-efficient internal
representation format, which evades extra paddings and duplicated storage of
oids. Altogether this format allows fetching a particular range by its index
in O(n).
Statistic gathering and selectivity estimation are implemented for multiranges.
For this purpose, stored multirange is approximated as union range without gaps.
This field will likely need improvements in the future.
Catversion is bumped.
Discussion: https://postgr.es/m/CALNJ-vSUpQ_Y%3DjXvTxt1VYFztaBSsWVXeF1y6gTYQ4bOiWDLgQ%40mail.gmail.com
Discussion: https://postgr.es/m/a0b8026459d1e6167933be2104a6174e7d40d0ab.camel%40j-davis.com#fe7218c83b08068bfffb0c5293eceda0
Author: Paul Jungwirth, revised by me
Reviewed-by: David Fetter, Corey Huinker, Jeff Davis, Pavel Stehule
Reviewed-by: Alvaro Herrera, Tom Lane, Isaac Morland, David G. Johnston
Reviewed-by: Zhihong Yu, Alexander Korotkov
2020-12-20 05:20:33 +01:00
|
|
|
bool isMultirange; /* true if auto-generated multirange type */
|
2002-05-11 00:36:27 +02:00
|
|
|
bool isDefined; /* true if typisdefined */
|
2015-08-05 01:34:12 +02:00
|
|
|
/* If needed, we'll create a "shell type" entry for it; link that here: */
|
2006-03-02 02:18:26 +01:00
|
|
|
struct _shellTypeInfo *shellType; /* shell-type entry, or NULL */
|
2003-12-06 04:00:16 +01:00
|
|
|
/* If it's a domain, we store links to its constraints here: */
|
|
|
|
int nDomChecks;
|
|
|
|
struct _constraintInfo *domChecks;
|
1996-07-09 08:22:35 +02:00
|
|
|
} TypeInfo;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2006-03-02 02:18:26 +01:00
|
|
|
typedef struct _shellTypeInfo
|
|
|
|
{
|
|
|
|
DumpableObject dobj;
|
|
|
|
|
|
|
|
TypeInfo *baseType; /* back link to associated base type */
|
|
|
|
} ShellTypeInfo;
|
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
typedef struct _funcInfo
|
|
|
|
{
|
2003-12-06 04:00:16 +01:00
|
|
|
DumpableObject dobj;
|
2021-12-06 18:39:45 +01:00
|
|
|
DumpableAcl dacl;
|
2021-12-31 17:39:26 +01:00
|
|
|
const char *rolname;
|
2001-08-10 20:57:42 +02:00
|
|
|
Oid lang;
|
1996-07-09 08:22:35 +02:00
|
|
|
int nargs;
|
2003-12-06 04:00:16 +01:00
|
|
|
Oid *argtypes;
|
|
|
|
Oid prorettype;
|
2023-06-04 19:05:54 +02:00
|
|
|
bool postponed_def; /* function must be postponed into post-data */
|
1996-07-09 08:22:35 +02:00
|
|
|
} FuncInfo;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2003-12-06 04:00:16 +01:00
|
|
|
/* AggInfo is a superset of FuncInfo */
|
2002-05-11 00:36:27 +02:00
|
|
|
typedef struct _aggInfo
|
2000-07-04 16:25:28 +02:00
|
|
|
{
|
2003-12-06 04:00:16 +01:00
|
|
|
FuncInfo aggfn;
|
2006-07-27 21:52:07 +02:00
|
|
|
/* we don't require any other fields at the moment */
|
2002-05-11 00:36:27 +02:00
|
|
|
} AggInfo;
|
|
|
|
|
|
|
|
typedef struct _oprInfo
|
|
|
|
{
|
2003-12-06 04:00:16 +01:00
|
|
|
DumpableObject dobj;
|
2021-12-31 17:39:26 +01:00
|
|
|
const char *rolname;
|
2012-01-05 19:34:07 +01:00
|
|
|
char oprkind;
|
2003-12-06 04:00:16 +01:00
|
|
|
Oid oprcode;
|
2002-05-11 00:36:27 +02:00
|
|
|
} OprInfo;
|
2000-07-04 16:25:28 +02:00
|
|
|
|
2016-03-24 03:01:35 +01:00
|
|
|
typedef struct _accessMethodInfo
|
|
|
|
{
|
|
|
|
DumpableObject dobj;
|
|
|
|
char amtype;
|
|
|
|
char *amhandler;
|
|
|
|
} AccessMethodInfo;
|
|
|
|
|
2002-07-30 23:56:04 +02:00
|
|
|
typedef struct _opclassInfo
|
|
|
|
{
|
2003-12-06 04:00:16 +01:00
|
|
|
DumpableObject dobj;
|
2021-12-31 17:39:26 +01:00
|
|
|
const char *rolname;
|
2002-07-30 23:56:04 +02:00
|
|
|
} OpclassInfo;
|
|
|
|
|
2007-01-23 18:54:50 +01:00
|
|
|
typedef struct _opfamilyInfo
|
|
|
|
{
|
|
|
|
DumpableObject dobj;
|
2021-12-31 17:39:26 +01:00
|
|
|
const char *rolname;
|
2007-01-23 18:54:50 +01:00
|
|
|
} OpfamilyInfo;
|
|
|
|
|
2011-02-12 14:54:13 +01:00
|
|
|
typedef struct _collInfo
|
|
|
|
{
|
|
|
|
DumpableObject dobj;
|
2021-12-31 17:39:26 +01:00
|
|
|
const char *rolname;
|
2011-02-12 14:54:13 +01:00
|
|
|
} CollInfo;
|
|
|
|
|
2003-11-21 23:32:49 +01:00
|
|
|
typedef struct _convInfo
|
|
|
|
{
|
2003-12-06 04:00:16 +01:00
|
|
|
DumpableObject dobj;
|
2021-12-31 17:39:26 +01:00
|
|
|
const char *rolname;
|
2003-11-21 23:32:49 +01:00
|
|
|
} ConvInfo;
|
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
typedef struct _tableInfo
|
|
|
|
{
|
2002-05-11 00:36:27 +02:00
|
|
|
/*
|
|
|
|
* These fields are collected for every table in the database.
|
|
|
|
*/
|
2003-12-06 04:00:16 +01:00
|
|
|
DumpableObject dobj;
|
2021-12-06 18:39:45 +01:00
|
|
|
DumpableAcl dacl;
|
2021-12-31 17:39:26 +01:00
|
|
|
const char *rolname;
|
2002-01-12 00:21:55 +01:00
|
|
|
char relkind;
|
2010-12-29 12:48:53 +01:00
|
|
|
char relpersistence; /* relation persistence */
|
2013-05-06 19:26:51 +02:00
|
|
|
bool relispopulated; /* relation is populated */
|
2015-08-12 15:52:10 +02:00
|
|
|
char relreplident; /* replica identifier */
|
2004-06-18 08:14:31 +02:00
|
|
|
char *reltablespace; /* relation tablespace */
|
2006-07-02 04:23:23 +02:00
|
|
|
char *reloptions; /* options specified by WITH (...) */
|
2016-01-03 01:04:45 +01:00
|
|
|
char *checkoption; /* WITH CHECK OPTION, if any */
|
2014-03-29 22:34:00 +01:00
|
|
|
char *toast_reloptions; /* WITH options for the TOAST table */
|
2002-01-12 00:21:55 +01:00
|
|
|
bool hasindex; /* does it have any indexes? */
|
2002-05-11 00:36:27 +02:00
|
|
|
bool hasrules; /* does it have any rules? */
|
2008-11-09 22:24:33 +01:00
|
|
|
bool hastriggers; /* does it have any triggers? */
|
2021-12-06 18:39:45 +01:00
|
|
|
bool hascolumnACLs; /* do any columns have non-default ACLs? */
|
Rename pg_rowsecurity -> pg_policy and other fixes
As pointed out by Robert, we should really have named pg_rowsecurity
pg_policy, as the objects stored in that catalog are policies. This
patch fixes that and updates the column names to start with 'pol' to
match the new catalog name.
The security consideration for COPY with row level security, also
pointed out by Robert, has also been addressed by remembering and
re-checking the OID of the relation initially referenced during COPY
processing, to make sure it hasn't changed under us by the time we
finish planning out the query which has been built.
Robert and Alvaro also commented on missing OCLASS and OBJECT entries
for POLICY (formerly ROWSECURITY or POLICY, depending) in various
places. This patch fixes that too, which also happens to add the
ability to COMMENT on policies.
In passing, attempt to improve the consistency of messages, comments,
and documentation as well. This removes various incarnations of
'row-security', 'row-level security', 'Row-security', etc, in favor
of 'policy', 'row level security' or 'row_security' as appropriate.
Happy Thanksgiving!
2014-11-27 07:06:36 +01:00
|
|
|
bool rowsec; /* is row security enabled? */
|
2015-10-05 03:05:08 +02:00
|
|
|
bool forcerowsec; /* is row security forced? */
|
2001-08-10 20:57:42 +02:00
|
|
|
bool hasoids; /* does it have OIDs? */
|
2015-12-24 16:42:58 +01:00
|
|
|
uint32 frozenxid; /* table's relfrozenxid */
|
|
|
|
uint32 minmxid; /* table's relminmxid */
|
|
|
|
Oid toast_oid; /* toast table's OID, or 0 if none */
|
|
|
|
uint32 toast_frozenxid; /* toast table's relfrozenxid, if any */
|
|
|
|
uint32 toast_minmxid; /* toast table's relminmxid */
|
2002-05-11 00:36:27 +02:00
|
|
|
int ncheck; /* # of CHECK expressions */
|
2021-12-06 18:25:48 +01:00
|
|
|
Oid reltype; /* OID of table's composite type, if any */
|
2021-12-06 18:49:49 +01:00
|
|
|
Oid reloftype; /* underlying type for typed table */
|
2020-03-25 17:19:31 +01:00
|
|
|
Oid foreign_server; /* foreign server oid, if applicable */
|
2006-08-21 02:57:26 +02:00
|
|
|
/* these two are set only if table is a sequence owned by a column: */
|
2003-12-06 04:00:16 +01:00
|
|
|
Oid owning_tab; /* OID of table owning sequence */
|
2002-08-19 21:33:36 +02:00
|
|
|
int owning_col; /* attr # of column owning sequence */
|
2017-04-06 14:33:16 +02:00
|
|
|
bool is_identity_sequence;
|
2014-03-29 22:34:00 +01:00
|
|
|
int relpages; /* table's size in pages (from pg_class) */
|
2021-12-06 19:23:07 +01:00
|
|
|
int toastpages; /* toast table's size in pages, if any */
|
2002-05-11 00:36:27 +02:00
|
|
|
|
|
|
|
bool interesting; /* true if need to collect more data */
|
Fix pg_dump's handling of circular dependencies in views.
pg_dump's traditional solution for breaking a circular dependency involving
a view was to create the view with CREATE TABLE and then later issue CREATE
RULE "_RETURN" ... to convert the table to a view, relying on the backend's
very very ancient code that supports making views that way. We've wanted
to get rid of that kluge for a long time, but the thing that finally
motivates doing something about it is the recognition that this method
fails with the --clean option, because it leads to issuing DROP RULE
"_RETURN" followed by DROP TABLE --- and the backend won't let you drop a
view's _RETURN rule.
Instead, let's break circular dependencies by initially creating the view
using CREATE VIEW AS SELECT NULL::columntype AS columnname, ... (so that
it has the right column names and types to support external references,
but no dependencies beyond the column data types), and then later dumping
the ON SELECT rule using the spelling CREATE OR REPLACE VIEW. This method
wasn't available when this code was originally written, but it's been
possible since PG 7.3, so it seems fine to start relying on it now.
To solve the --clean problem, make the dropStmt for an ON SELECT rule
be CREATE OR REPLACE VIEW with the same dummy target list as above.
In this way, during the DROP phase, we first reduce the view to have
no extra dependencies, and then we can drop it entirely when we've
gotten rid of whatever had a circular dependency on it.
(Note: this should work adequately well with the --if-exists option, since
the CREATE OR REPLACE VIEW will go through whether the view exists or not.
It could fail if the view exists with a conflicting column set, but we
don't really support --clean against a non-matching database anyway.)
This allows cleaning up some other kluges inside pg_dump, notably that
we don't need a notion of reloptions attached to a rule anymore.
Although this is a bug fix, commit to HEAD only for now. The problem's
existed for a long time and we've had relatively few complaints, so it
doesn't really seem worth taking risks to fix it in the back branches.
We might revisit that choice if no problems emerge.
Discussion: <19092.1479325184@sss.pgh.pa.us>
2016-11-17 21:25:59 +01:00
|
|
|
bool dummy_view; /* view's real definition must be postponed */
|
2014-03-29 22:34:00 +01:00
|
|
|
bool postponed_def; /* matview must be postponed into post-data */
|
2017-05-05 04:17:52 +02:00
|
|
|
bool ispartition; /* is table a partition? */
|
Fix pg_dump for hash partitioning on enum columns.
Hash partitioning on an enum is problematic because the hash codes are
derived from the OIDs assigned to the enum values, which will almost
certainly be different after a dump-and-reload than they were before.
This means that some rows probably end up in different partitions than
before, causing restore to fail because of partition constraint
violations. (pg_upgrade dodges this problem by using hacks to force
the enum values to keep the same OIDs, but that's not possible nor
desirable for pg_dump.)
Users can work around that by specifying --load-via-partition-root,
but since that's a dump-time not restore-time decision, one might
find out the need for it far too late. Instead, teach pg_dump to
apply that option automatically when dealing with a partitioned
table that has hash-on-enum partitioning.
Also deal with a pre-existing issue for --load-via-partition-root
mode: in a parallel restore, we try to TRUNCATE target tables just
before loading them, in order to enable some backend optimizations.
This is bad when using --load-via-partition-root because (a) we're
likely to suffer deadlocks from restore jobs trying to restore rows
into other partitions than they came from, and (b) if we miss getting
a deadlock we might still lose data due to a TRUNCATE removing rows
from some already-completed restore job.
The fix for this is conceptually simple: just don't TRUNCATE if we're
dealing with a --load-via-partition-root case. The tricky bit is for
pg_restore to identify those cases. In dumps using COPY commands we
can inspect each COPY command to see if it targets the nominal target
table or some ancestor. However, in dumps using INSERT commands it's
pretty impractical to examine the INSERTs in advance. To provide a
solution for that going forward, modify pg_dump to mark TABLE DATA
items that are using --load-via-partition-root with a comment.
(This change also responds to a complaint from Robert Haas that
the dump output for --load-via-partition-root is pretty confusing.)
pg_restore checks for the special comment as well as checking the
COPY command if present. This will fail to identify the combination
of --load-via-partition-root and --inserts in pre-existing dump files,
but that should be a pretty rare case in the field. If it does
happen you will probably get a deadlock failure that you can work
around by not using parallel restore, which is the same as before
this bug fix.
Having done this, there seems no remaining reason for the alarmism
in the pg_dump man page about combining --load-via-partition-root
with parallel restore, so remove that warning.
Patch by me; thanks to Julien Rouhaud for review. Back-patch to
v11 where hash partitioning was introduced.
Discussion: https://postgr.es/m/1376149.1675268279@sss.pgh.pa.us
2023-03-17 18:31:40 +01:00
|
|
|
bool unsafe_partitions; /* is it an unsafe partitioned table? */
|
2002-05-11 00:36:27 +02:00
|
|
|
|
2023-03-17 18:43:10 +01:00
|
|
|
int numParents; /* number of (immediate) parent tables */
|
|
|
|
struct _tableInfo **parents; /* TableInfos of immediate parents */
|
|
|
|
|
2002-05-11 00:36:27 +02:00
|
|
|
/*
|
|
|
|
* These fields are computed only if we decide the table is interesting
|
|
|
|
* (it's either a table to dump, or a direct parent of a dumpable table).
|
|
|
|
*/
|
1996-07-09 08:22:35 +02:00
|
|
|
int numatts; /* number of attributes */
|
|
|
|
char **attnames; /* the attribute names */
|
2002-05-11 00:36:27 +02:00
|
|
|
char **atttypnames; /* attribute type names */
|
2002-07-31 19:19:54 +02:00
|
|
|
int *attstattarget; /* attribute statistics targets */
|
2003-03-20 07:26:30 +01:00
|
|
|
char *attstorage; /* attribute storage scheme */
|
|
|
|
char *typstorage; /* type storage scheme */
|
2002-08-19 21:33:36 +02:00
|
|
|
bool *attisdropped; /* true if attr is dropped; don't dump it */
|
2017-04-06 14:33:16 +02:00
|
|
|
char *attidentity;
|
2019-03-30 08:13:09 +01:00
|
|
|
char *attgenerated;
|
2009-02-17 16:41:50 +01:00
|
|
|
int *attlen; /* attribute length, used by binary_upgrade */
|
|
|
|
char *attalign; /* attribute align, used by binary_upgrade */
|
2002-10-09 18:20:25 +02:00
|
|
|
bool *attislocal; /* true if attr has local definition */
|
2010-01-22 17:40:19 +01:00
|
|
|
char **attoptions; /* per-attribute options */
|
2011-03-10 23:30:18 +01:00
|
|
|
Oid *attcollation; /* per-attribute collation selection */
|
2021-03-20 20:01:10 +01:00
|
|
|
char *attcompression; /* per-attribute compression method */
|
2011-08-05 19:24:03 +02:00
|
|
|
char **attfdwoptions; /* per-attribute fdw options */
|
2018-06-22 14:42:36 +02:00
|
|
|
char **attmissingval; /* per attribute missing value */
|
Catalog not-null constraints
We now create contype='n' pg_constraint rows for not-null constraints.
We propagate these constraints to other tables during operations such as
adding inheritance relationships, creating and attaching partitions and
creating tables LIKE other tables. We also spawn not-null constraints
for inheritance child tables when their parents have primary keys.
These related constraints mostly follow the well-known rules of
conislocal and coninhcount that we have for CHECK constraints, with some
adaptations: for example, as opposed to CHECK constraints, we don't
match not-null ones by name when descending a hierarchy to alter it,
instead matching by column name that they apply to. This means we don't
require the constraint names to be identical across a hierarchy.
For now, we omit them for system catalogs. Maybe this is worth
reconsidering. We don't support NOT VALID nor DEFERRABLE clauses
either; these can be added as separate features later (this patch is
already large and complicated enough.)
psql shows these constraints in \d+.
pg_dump requires some ad-hoc hacks, particularly when dumping a primary
key. We now create one "throwaway" not-null constraint for each column
in the PK together with the CREATE TABLE command, and once the PK is
created, all those throwaway constraints are removed. This avoids
having to check each tuple for nullness when the dump restores the
primary key creation.
pg_upgrading from an older release requires a somewhat brittle procedure
to create a constraint state that matches what would be created if the
database were being created fresh in Postgres 17. I have tested all the
scenarios I could think of, and it works correctly as far as I can tell,
but I could have neglected weird cases.
This patch has been very long in the making. The first patch was
written by Bernd Helmle in 2010 to add a new pg_constraint.contype value
('n'), which I (Álvaro) then hijacked in 2011 and 2012, until that one
was killed by the realization that we ought to use contype='c' instead:
manufactured CHECK constraints. However, later SQL standard
development, as well as nonobvious emergent properties of that design
(mostly, failure to distinguish them from "normal" CHECK constraints as
well as the performance implication of having to test the CHECK
expression) led us to reconsider this choice, so now the current
implementation uses contype='n' again. During Postgres 16 this had
already been introduced by commit e056c557aef4, but there were some
problems mainly with the pg_upgrade procedure that couldn't be fixed in
reasonable time, so it was reverted.
In 2016 Vitaly Burovoy also worked on this feature[1] but found no
consensus for his proposed approach, which was claimed to be closer to
the letter of the standard, requiring an additional pg_attribute column
to track the OID of the not-null constraint for that column.
[1] https://postgr.es/m/CAKOSWNkN6HSyatuys8xZxzRCR-KL1OkHS5-b9qd9bf1Rad3PLA@mail.gmail.com
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>
Author: Bernd Helmle <mailings@oopsware.de>
Reviewed-by: Justin Pryzby <pryzby@telsasoft.com>
Reviewed-by: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Reviewed-by: Dean Rasheed <dean.a.rasheed@gmail.com>
2023-08-25 13:31:24 +02:00
|
|
|
char **notnull_constrs; /* NOT NULL constraint names. If null,
|
|
|
|
* there isn't one on this column. If
|
|
|
|
* empty string, unnamed constraint
|
|
|
|
* (pre-v17) */
|
|
|
|
bool *notnull_noinh; /* NOT NULL is NO INHERIT */
|
|
|
|
bool *notnull_throwaway; /* drop the NOT NULL constraint later */
|
|
|
|
bool *notnull_inh; /* true if NOT NULL has no local definition */
|
2012-02-10 19:28:05 +01:00
|
|
|
struct _attrDefInfo **attrdefs; /* DEFAULT expressions */
|
2003-12-06 04:00:16 +01:00
|
|
|
struct _constraintInfo *checkexprs; /* CHECK constraints */
|
2017-04-06 14:33:16 +02:00
|
|
|
bool needs_override; /* has GENERATED ALWAYS AS IDENTITY */
|
2019-03-06 18:54:38 +01:00
|
|
|
char *amname; /* relation access method */
|
2002-05-11 00:36:27 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Stuff computed only for dumpable tables.
|
|
|
|
*/
|
Local partitioned indexes
When CREATE INDEX is run on a partitioned table, create catalog entries
for an index on the partitioned table (which is just a placeholder since
the table proper has no data of its own), and recurse to create actual
indexes on the existing partitions; create them in future partitions
also.
As a convenience gadget, if the new index definition matches some
existing index in partitions, these are picked up and used instead of
creating new ones. Whichever way these indexes come about, they become
attached to the index on the parent table and are dropped alongside it,
and cannot be dropped on isolation unless they are detached first.
To support pg_dump'ing these indexes, add commands
CREATE INDEX ON ONLY <table>
(which creates the index on the parent partitioned table, without
recursing) and
ALTER INDEX ATTACH PARTITION
(which is used after the indexes have been created individually on each
partition, to attach them to the parent index). These reconstruct prior
database state exactly.
Reviewed-by: (in alphabetical order) Peter Eisentraut, Robert Haas, Amit
Langote, Jesper Pedersen, Simon Riggs, David Rowley
Discussion: https://postgr.es/m/20171113170646.gzweigyrgg6pwsg4@alvherre.pgsql
2018-01-19 15:49:22 +01:00
|
|
|
int numIndexes; /* number of indexes */
|
|
|
|
struct _indxInfo *indexes; /* indexes */
|
2008-09-08 17:26:23 +02:00
|
|
|
struct _tableDataInfo *dataObj; /* TableDataInfo, if dumping its data */
|
2016-02-04 06:26:10 +01:00
|
|
|
int numTriggers; /* number of triggers for table */
|
|
|
|
struct _triggerInfo *triggers; /* array of TriggerInfo structs */
|
1996-07-09 08:22:35 +02:00
|
|
|
} TableInfo;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2021-01-12 03:09:03 +01:00
|
|
|
typedef struct _tableAttachInfo
|
|
|
|
{
|
|
|
|
DumpableObject dobj;
|
|
|
|
TableInfo *parentTbl; /* link to partitioned table */
|
|
|
|
TableInfo *partitionTbl; /* link to partition */
|
|
|
|
} TableAttachInfo;
|
|
|
|
|
2003-12-06 04:00:16 +01:00
|
|
|
typedef struct _attrDefInfo
|
|
|
|
{
|
2012-02-10 19:28:05 +01:00
|
|
|
DumpableObject dobj; /* note: dobj.name is name of table */
|
2003-12-06 04:00:16 +01:00
|
|
|
TableInfo *adtable; /* link to table of attribute */
|
|
|
|
int adnum;
|
|
|
|
char *adef_expr; /* decompiled DEFAULT expression */
|
2017-08-16 06:22:32 +02:00
|
|
|
bool separate; /* true if must dump as separate item */
|
2003-12-06 04:00:16 +01:00
|
|
|
} AttrDefInfo;
|
|
|
|
|
|
|
|
typedef struct _tableDataInfo
|
|
|
|
{
|
|
|
|
DumpableObject dobj;
|
|
|
|
TableInfo *tdtable; /* link to table to dump */
|
2011-02-08 22:08:41 +01:00
|
|
|
char *filtercond; /* WHERE condition to limit rows dumped */
|
2003-12-06 04:00:16 +01:00
|
|
|
} TableDataInfo;
|
|
|
|
|
|
|
|
typedef struct _indxInfo
|
|
|
|
{
|
|
|
|
DumpableObject dobj;
|
|
|
|
TableInfo *indextable; /* link to table the index is for */
|
|
|
|
char *indexdef;
|
2004-08-02 06:28:29 +02:00
|
|
|
char *tablespace; /* tablespace in which index is stored */
|
2016-01-03 01:04:45 +01:00
|
|
|
char *indreloptions; /* options specified by WITH (...) */
|
Include ALTER INDEX SET STATISTICS in pg_dump
The new grammar pattern of ALTER INDEX SET STATISTICS able to use column
numbers on top of the existing column names introduced by commit 5b6d13e
forgot to add support for the feature in pg_dump, so defining statistics
on index columns was missing from the dumps, potentially causing silent
planning problems with a subsequent restore.
pg_dump ought to not use column names in what it generates as these are
automatically generated by the server and could conflict with real
relation attributes with matching patterns. "expr" and "exprN", N
incremented automatically after the creation of the first one, are used
as default attribute names for index expressions, and that could easily
match what is defined in other relations, causing the dumps to fail if
some of those attributes are renamed at some point. So to avoid any
problems, the new grammar with column numbers gets used.
Reported-by: Ronan Dunklau
Author: Michael Paquier
Reviewed-by: Tom Lane, Adrien Nayrat, Amul Sul
Discussion: https://postgr.es/m/CAARsnT3UQ4V=yDNW468w8RqHfYiY9mpn2r_c5UkBJ97NAApUEw@mail.gmail.com
Backpatch-through: 11, where the new syntax has been introduced.
2018-12-18 01:28:16 +01:00
|
|
|
char *indstatcols; /* column numbers with statistics */
|
|
|
|
char *indstatvals; /* statistic values for columns */
|
2018-04-07 22:00:39 +02:00
|
|
|
int indnkeyattrs; /* number of index key attributes */
|
|
|
|
int indnattrs; /* total number of index attributes */
|
|
|
|
Oid *indkeys; /* In spite of the name 'indkeys' this field
|
|
|
|
* contains both key and nonkey attributes */
|
2003-12-06 04:00:16 +01:00
|
|
|
bool indisclustered;
|
2013-11-08 18:30:43 +01:00
|
|
|
bool indisreplident;
|
2022-02-03 11:29:54 +01:00
|
|
|
bool indnullsnotdistinct;
|
2020-09-02 02:43:23 +02:00
|
|
|
Oid parentidx; /* if a partition, parent index OID */
|
2019-10-17 09:58:01 +02:00
|
|
|
SimplePtrList partattaches; /* if partitioned, partition attach objects */
|
|
|
|
|
2003-12-06 04:00:16 +01:00
|
|
|
/* if there is an associated constraint object, its dumpId: */
|
|
|
|
DumpId indexconstraint;
|
|
|
|
} IndxInfo;
|
|
|
|
|
Local partitioned indexes
When CREATE INDEX is run on a partitioned table, create catalog entries
for an index on the partitioned table (which is just a placeholder since
the table proper has no data of its own), and recurse to create actual
indexes on the existing partitions; create them in future partitions
also.
As a convenience gadget, if the new index definition matches some
existing index in partitions, these are picked up and used instead of
creating new ones. Whichever way these indexes come about, they become
attached to the index on the parent table and are dropped alongside it,
and cannot be dropped on isolation unless they are detached first.
To support pg_dump'ing these indexes, add commands
CREATE INDEX ON ONLY <table>
(which creates the index on the parent partitioned table, without
recursing) and
ALTER INDEX ATTACH PARTITION
(which is used after the indexes have been created individually on each
partition, to attach them to the parent index). These reconstruct prior
database state exactly.
Reviewed-by: (in alphabetical order) Peter Eisentraut, Robert Haas, Amit
Langote, Jesper Pedersen, Simon Riggs, David Rowley
Discussion: https://postgr.es/m/20171113170646.gzweigyrgg6pwsg4@alvherre.pgsql
2018-01-19 15:49:22 +01:00
|
|
|
typedef struct _indexAttachInfo
|
|
|
|
{
|
|
|
|
DumpableObject dobj;
|
|
|
|
IndxInfo *parentIdx; /* link to index on partitioned table */
|
|
|
|
IndxInfo *partitionIdx; /* link to index on partition */
|
|
|
|
} IndexAttachInfo;
|
|
|
|
|
Implement multivariate n-distinct coefficients
Add support for explicitly declared statistic objects (CREATE
STATISTICS), allowing collection of statistics on more complex
combinations that individual table columns. Companion commands DROP
STATISTICS and ALTER STATISTICS ... OWNER TO / SET SCHEMA / RENAME are
added too. All this DDL has been designed so that more statistic types
can be added later on, such as multivariate most-common-values and
multivariate histograms between columns of a single table, leaving room
for permitting columns on multiple tables, too, as well as expressions.
This commit only adds support for collection of n-distinct coefficient
on user-specified sets of columns in a single table. This is useful to
estimate number of distinct groups in GROUP BY and DISTINCT clauses;
estimation errors there can cause over-allocation of memory in hashed
aggregates, for instance, so it's a worthwhile problem to solve. A new
special pseudo-type pg_ndistinct is used.
(num-distinct estimation was deemed sufficiently useful by itself that
this is worthwhile even if no further statistic types are added
immediately; so much so that another version of essentially the same
functionality was submitted by Kyotaro Horiguchi:
https://postgr.es/m/20150828.173334.114731693.horiguchi.kyotaro@lab.ntt.co.jp
though this commit does not use that code.)
Author: Tomas Vondra. Some code rework by Álvaro.
Reviewed-by: Dean Rasheed, David Rowley, Kyotaro Horiguchi, Jeff Janes,
Ideriha Takeshi
Discussion: https://postgr.es/m/543AFA15.4080608@fuzzy.cz
https://postgr.es/m/20170320190220.ixlaueanxegqd5gr@alvherre.pgsql
2017-03-24 18:06:10 +01:00
|
|
|
typedef struct _statsExtInfo
|
|
|
|
{
|
|
|
|
DumpableObject dobj;
|
2023-12-29 16:57:11 +01:00
|
|
|
const char *rolname; /* owner */
|
|
|
|
TableInfo *stattable; /* link to table the stats are for */
|
Allow setting statistics target for extended statistics
When building statistics, we need to decide how many rows to sample and
how accurate the resulting statistics should be. Until now, it was not
possible to explicitly define statistics target for extended statistics
objects, the value was always computed from the per-attribute targets
with a fallback to the system-wide default statistics target.
That's a bit inconvenient, as it ties together the statistics target set
for per-column and extended statistics. In some cases it may be useful
to require larger sample / higher accuracy for extended statics (or the
other way around), but with this approach that's not possible.
So this commit introduces a new command, allowing to specify statistics
target for individual extended statistics objects, overriding the value
derived from per-attribute targets (and the system default).
ALTER STATISTICS stat_name SET STATISTICS target_value;
When determining statistics target for an extended statistics object we
first look at this explicitly set value. When this value is -1, we fall
back to the old formula, looking at the per-attribute targets first and
then the system default. This means the behavior is backwards compatible
with older PostgreSQL releases.
Author: Tomas Vondra
Discussion: https://postgr.es/m/20190618213357.vli3i23vpkset2xd@development
Reviewed-by: Kirk Jamison, Dean Rasheed
2019-09-10 20:09:27 +02:00
|
|
|
int stattarget; /* statistics target */
|
Implement multivariate n-distinct coefficients
Add support for explicitly declared statistic objects (CREATE
STATISTICS), allowing collection of statistics on more complex
combinations that individual table columns. Companion commands DROP
STATISTICS and ALTER STATISTICS ... OWNER TO / SET SCHEMA / RENAME are
added too. All this DDL has been designed so that more statistic types
can be added later on, such as multivariate most-common-values and
multivariate histograms between columns of a single table, leaving room
for permitting columns on multiple tables, too, as well as expressions.
This commit only adds support for collection of n-distinct coefficient
on user-specified sets of columns in a single table. This is useful to
estimate number of distinct groups in GROUP BY and DISTINCT clauses;
estimation errors there can cause over-allocation of memory in hashed
aggregates, for instance, so it's a worthwhile problem to solve. A new
special pseudo-type pg_ndistinct is used.
(num-distinct estimation was deemed sufficiently useful by itself that
this is worthwhile even if no further statistic types are added
immediately; so much so that another version of essentially the same
functionality was submitted by Kyotaro Horiguchi:
https://postgr.es/m/20150828.173334.114731693.horiguchi.kyotaro@lab.ntt.co.jp
though this commit does not use that code.)
Author: Tomas Vondra. Some code rework by Álvaro.
Reviewed-by: Dean Rasheed, David Rowley, Kyotaro Horiguchi, Jeff Janes,
Ideriha Takeshi
Discussion: https://postgr.es/m/543AFA15.4080608@fuzzy.cz
https://postgr.es/m/20170320190220.ixlaueanxegqd5gr@alvherre.pgsql
2017-03-24 18:06:10 +01:00
|
|
|
} StatsExtInfo;
|
|
|
|
|
2003-12-06 04:00:16 +01:00
|
|
|
typedef struct _ruleInfo
|
|
|
|
{
|
|
|
|
DumpableObject dobj;
|
|
|
|
TableInfo *ruletable; /* link to table the rule is for */
|
|
|
|
char ev_type;
|
|
|
|
bool is_instead;
|
2007-03-20 00:38:32 +01:00
|
|
|
char ev_enabled;
|
2017-08-16 06:22:32 +02:00
|
|
|
bool separate; /* true if must dump as separate item */
|
2009-01-27 13:40:15 +01:00
|
|
|
/* separate is always true for non-ON SELECT rules */
|
2003-12-06 04:00:16 +01:00
|
|
|
} RuleInfo;
|
|
|
|
|
|
|
|
typedef struct _triggerInfo
|
|
|
|
{
|
|
|
|
DumpableObject dobj;
|
|
|
|
TableInfo *tgtable; /* link to table the trigger is for */
|
2007-03-20 00:38:32 +01:00
|
|
|
char tgenabled;
|
2022-01-05 23:00:13 +01:00
|
|
|
bool tgispartition;
|
2009-10-09 23:02:56 +02:00
|
|
|
char *tgdef;
|
2003-12-06 04:00:16 +01:00
|
|
|
} TriggerInfo;
|
|
|
|
|
2012-07-18 16:16:16 +02:00
|
|
|
typedef struct _evttriggerInfo
|
|
|
|
{
|
|
|
|
DumpableObject dobj;
|
|
|
|
char *evtname;
|
|
|
|
char *evtevent;
|
2021-12-31 17:39:26 +01:00
|
|
|
const char *evtowner;
|
2012-07-18 16:16:16 +02:00
|
|
|
char *evttags;
|
|
|
|
char *evtfname;
|
|
|
|
char evtenabled;
|
|
|
|
} EventTriggerInfo;
|
|
|
|
|
2003-12-06 04:00:16 +01:00
|
|
|
/*
|
|
|
|
* struct ConstraintInfo is used for all constraint types. However we
|
|
|
|
* use a different objType for foreign key constraints, to make it easier
|
|
|
|
* to sort them the way we want.
|
2009-07-29 22:56:21 +02:00
|
|
|
*
|
|
|
|
* Note: condeferrable and condeferred are currently only valid for
|
|
|
|
* unique/primary-key constraints. Otherwise that info is in condef.
|
2003-12-06 04:00:16 +01:00
|
|
|
*/
|
|
|
|
typedef struct _constraintInfo
|
|
|
|
{
|
|
|
|
DumpableObject dobj;
|
|
|
|
TableInfo *contable; /* NULL if domain constraint */
|
|
|
|
TypeInfo *condomain; /* NULL if table constraint */
|
|
|
|
char contype;
|
|
|
|
char *condef; /* definition, if CHECK or FOREIGN KEY */
|
2008-09-08 17:26:23 +02:00
|
|
|
Oid confrelid; /* referenced table, if FOREIGN KEY */
|
2003-12-06 04:00:16 +01:00
|
|
|
DumpId conindex; /* identifies associated index if any */
|
2017-08-16 06:22:32 +02:00
|
|
|
bool condeferrable; /* true if constraint is DEFERRABLE */
|
|
|
|
bool condeferred; /* true if constraint is INITIALLY DEFERRED */
|
2024-03-05 11:15:06 +01:00
|
|
|
bool conperiod; /* true if the constraint is WITHOUT OVERLAPS */
|
2017-08-16 06:22:32 +02:00
|
|
|
bool conislocal; /* true if constraint has local definition */
|
|
|
|
bool separate; /* true if must dump as separate item */
|
2003-12-06 04:00:16 +01:00
|
|
|
} ConstraintInfo;
|
|
|
|
|
|
|
|
typedef struct _procLangInfo
|
|
|
|
{
|
|
|
|
DumpableObject dobj;
|
2021-12-06 18:39:45 +01:00
|
|
|
DumpableAcl dacl;
|
2003-12-06 04:00:16 +01:00
|
|
|
bool lanpltrusted;
|
|
|
|
Oid lanplcallfoid;
|
2009-09-23 01:43:43 +02:00
|
|
|
Oid laninline;
|
2003-12-06 04:00:16 +01:00
|
|
|
Oid lanvalidator;
|
2021-12-31 17:39:26 +01:00
|
|
|
const char *lanowner;
|
2003-12-06 04:00:16 +01:00
|
|
|
} ProcLangInfo;
|
|
|
|
|
|
|
|
typedef struct _castInfo
|
|
|
|
{
|
|
|
|
DumpableObject dobj;
|
|
|
|
Oid castsource;
|
|
|
|
Oid casttarget;
|
|
|
|
Oid castfunc;
|
|
|
|
char castcontext;
|
2008-10-31 09:39:22 +01:00
|
|
|
char castmethod;
|
2003-12-06 04:00:16 +01:00
|
|
|
} CastInfo;
|
|
|
|
|
2015-04-26 16:33:14 +02:00
|
|
|
typedef struct _transformInfo
|
|
|
|
{
|
|
|
|
DumpableObject dobj;
|
|
|
|
Oid trftype;
|
|
|
|
Oid trflang;
|
|
|
|
Oid trffromsql;
|
|
|
|
Oid trftosql;
|
|
|
|
} TransformInfo;
|
|
|
|
|
2003-12-06 04:00:16 +01:00
|
|
|
/* InhInfo isn't a DumpableObject, just temporary state */
|
1996-07-09 08:22:35 +02:00
|
|
|
typedef struct _inhInfo
|
|
|
|
{
|
2003-12-06 04:00:16 +01:00
|
|
|
Oid inhrelid; /* OID of a child table */
|
|
|
|
Oid inhparent; /* OID of its parent */
|
1996-07-09 08:22:35 +02:00
|
|
|
} InhInfo;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2007-08-21 03:11:32 +02:00
|
|
|
typedef struct _prsInfo
|
|
|
|
{
|
|
|
|
DumpableObject dobj;
|
|
|
|
Oid prsstart;
|
|
|
|
Oid prstoken;
|
|
|
|
Oid prsend;
|
|
|
|
Oid prsheadline;
|
|
|
|
Oid prslextype;
|
|
|
|
} TSParserInfo;
|
|
|
|
|
|
|
|
typedef struct _dictInfo
|
|
|
|
{
|
|
|
|
DumpableObject dobj;
|
2021-12-31 17:39:26 +01:00
|
|
|
const char *rolname;
|
2007-08-21 03:11:32 +02:00
|
|
|
Oid dicttemplate;
|
|
|
|
char *dictinitoption;
|
|
|
|
} TSDictInfo;
|
|
|
|
|
|
|
|
typedef struct _tmplInfo
|
|
|
|
{
|
|
|
|
DumpableObject dobj;
|
|
|
|
Oid tmplinit;
|
|
|
|
Oid tmpllexize;
|
|
|
|
} TSTemplateInfo;
|
|
|
|
|
|
|
|
typedef struct _cfgInfo
|
|
|
|
{
|
|
|
|
DumpableObject dobj;
|
2021-12-31 17:39:26 +01:00
|
|
|
const char *rolname;
|
2007-08-21 03:11:32 +02:00
|
|
|
Oid cfgparser;
|
|
|
|
} TSConfigInfo;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2008-12-19 17:25:19 +01:00
|
|
|
typedef struct _fdwInfo
|
|
|
|
{
|
|
|
|
DumpableObject dobj;
|
2021-12-06 18:39:45 +01:00
|
|
|
DumpableAcl dacl;
|
2021-12-31 17:39:26 +01:00
|
|
|
const char *rolname;
|
2011-02-19 06:06:18 +01:00
|
|
|
char *fdwhandler;
|
2009-02-24 11:06:36 +01:00
|
|
|
char *fdwvalidator;
|
2008-12-19 17:25:19 +01:00
|
|
|
char *fdwoptions;
|
|
|
|
} FdwInfo;
|
|
|
|
|
|
|
|
typedef struct _foreignServerInfo
|
|
|
|
{
|
|
|
|
DumpableObject dobj;
|
2021-12-06 18:39:45 +01:00
|
|
|
DumpableAcl dacl;
|
2021-12-31 17:39:26 +01:00
|
|
|
const char *rolname;
|
2008-12-19 17:25:19 +01:00
|
|
|
Oid srvfdw;
|
|
|
|
char *srvtype;
|
|
|
|
char *srvversion;
|
|
|
|
char *srvoptions;
|
|
|
|
} ForeignServerInfo;
|
|
|
|
|
2009-10-05 21:24:49 +02:00
|
|
|
typedef struct _defaultACLInfo
|
|
|
|
{
|
|
|
|
DumpableObject dobj;
|
2021-12-06 18:39:45 +01:00
|
|
|
DumpableAcl dacl;
|
2021-12-31 17:39:26 +01:00
|
|
|
const char *defaclrole;
|
2009-10-05 21:24:49 +02:00
|
|
|
char defaclobjtype;
|
|
|
|
} DefaultACLInfo;
|
|
|
|
|
2022-12-05 08:52:11 +01:00
|
|
|
typedef struct _loInfo
|
2010-02-18 02:29:10 +01:00
|
|
|
{
|
|
|
|
DumpableObject dobj;
|
2021-12-06 18:39:45 +01:00
|
|
|
DumpableAcl dacl;
|
2021-12-31 17:39:26 +01:00
|
|
|
const char *rolname;
|
2022-12-05 08:52:11 +01:00
|
|
|
} LoInfo;
|
2010-02-18 02:29:10 +01:00
|
|
|
|
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
|
|
|
/*
|
Rename pg_rowsecurity -> pg_policy and other fixes
As pointed out by Robert, we should really have named pg_rowsecurity
pg_policy, as the objects stored in that catalog are policies. This
patch fixes that and updates the column names to start with 'pol' to
match the new catalog name.
The security consideration for COPY with row level security, also
pointed out by Robert, has also been addressed by remembering and
re-checking the OID of the relation initially referenced during COPY
processing, to make sure it hasn't changed under us by the time we
finish planning out the query which has been built.
Robert and Alvaro also commented on missing OCLASS and OBJECT entries
for POLICY (formerly ROWSECURITY or POLICY, depending) in various
places. This patch fixes that too, which also happens to add the
ability to COMMENT on policies.
In passing, attempt to improve the consistency of messages, comments,
and documentation as well. This removes various incarnations of
'row-security', 'row-level security', 'Row-security', etc, in favor
of 'policy', 'row level security' or 'row_security' as appropriate.
Happy Thanksgiving!
2014-11-27 07:06:36 +01:00
|
|
|
* The PolicyInfo struct is used to represent policies on a table and
|
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
|
|
|
* to indicate if a table has RLS enabled (ENABLE ROW SECURITY). If
|
Rename pg_rowsecurity -> pg_policy and other fixes
As pointed out by Robert, we should really have named pg_rowsecurity
pg_policy, as the objects stored in that catalog are policies. This
patch fixes that and updates the column names to start with 'pol' to
match the new catalog name.
The security consideration for COPY with row level security, also
pointed out by Robert, has also been addressed by remembering and
re-checking the OID of the relation initially referenced during COPY
processing, to make sure it hasn't changed under us by the time we
finish planning out the query which has been built.
Robert and Alvaro also commented on missing OCLASS and OBJECT entries
for POLICY (formerly ROWSECURITY or POLICY, depending) in various
places. This patch fixes that too, which also happens to add the
ability to COMMENT on policies.
In passing, attempt to improve the consistency of messages, comments,
and documentation as well. This removes various incarnations of
'row-security', 'row-level security', 'Row-security', etc, in favor
of 'policy', 'row level security' or 'row_security' as appropriate.
Happy Thanksgiving!
2014-11-27 07:06:36 +01:00
|
|
|
* polname is NULL, then the record indicates ENABLE ROW SECURITY, while if
|
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
|
|
|
* it's non-NULL then this is a regular policy definition.
|
|
|
|
*/
|
Rename pg_rowsecurity -> pg_policy and other fixes
As pointed out by Robert, we should really have named pg_rowsecurity
pg_policy, as the objects stored in that catalog are policies. This
patch fixes that and updates the column names to start with 'pol' to
match the new catalog name.
The security consideration for COPY with row level security, also
pointed out by Robert, has also been addressed by remembering and
re-checking the OID of the relation initially referenced during COPY
processing, to make sure it hasn't changed under us by the time we
finish planning out the query which has been built.
Robert and Alvaro also commented on missing OCLASS and OBJECT entries
for POLICY (formerly ROWSECURITY or POLICY, depending) in various
places. This patch fixes that too, which also happens to add the
ability to COMMENT on policies.
In passing, attempt to improve the consistency of messages, comments,
and documentation as well. This removes various incarnations of
'row-security', 'row-level security', 'Row-security', etc, in favor
of 'policy', 'row level security' or 'row_security' as appropriate.
Happy Thanksgiving!
2014-11-27 07:06:36 +01:00
|
|
|
typedef struct _policyInfo
|
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
|
|
|
{
|
|
|
|
DumpableObject dobj;
|
Rename pg_rowsecurity -> pg_policy and other fixes
As pointed out by Robert, we should really have named pg_rowsecurity
pg_policy, as the objects stored in that catalog are policies. This
patch fixes that and updates the column names to start with 'pol' to
match the new catalog name.
The security consideration for COPY with row level security, also
pointed out by Robert, has also been addressed by remembering and
re-checking the OID of the relation initially referenced during COPY
processing, to make sure it hasn't changed under us by the time we
finish planning out the query which has been built.
Robert and Alvaro also commented on missing OCLASS and OBJECT entries
for POLICY (formerly ROWSECURITY or POLICY, depending) in various
places. This patch fixes that too, which also happens to add the
ability to COMMENT on policies.
In passing, attempt to improve the consistency of messages, comments,
and documentation as well. This removes various incarnations of
'row-security', 'row-level security', 'Row-security', etc, in favor
of 'policy', 'row level security' or 'row_security' as appropriate.
Happy Thanksgiving!
2014-11-27 07:06:36 +01:00
|
|
|
TableInfo *poltable;
|
|
|
|
char *polname; /* null indicates RLS is enabled on rel */
|
2016-12-05 21:50:55 +01:00
|
|
|
char polcmd;
|
|
|
|
bool polpermissive;
|
Rename pg_rowsecurity -> pg_policy and other fixes
As pointed out by Robert, we should really have named pg_rowsecurity
pg_policy, as the objects stored in that catalog are policies. This
patch fixes that and updates the column names to start with 'pol' to
match the new catalog name.
The security consideration for COPY with row level security, also
pointed out by Robert, has also been addressed by remembering and
re-checking the OID of the relation initially referenced during COPY
processing, to make sure it hasn't changed under us by the time we
finish planning out the query which has been built.
Robert and Alvaro also commented on missing OCLASS and OBJECT entries
for POLICY (formerly ROWSECURITY or POLICY, depending) in various
places. This patch fixes that too, which also happens to add the
ability to COMMENT on policies.
In passing, attempt to improve the consistency of messages, comments,
and documentation as well. This removes various incarnations of
'row-security', 'row-level security', 'Row-security', etc, in favor
of 'policy', 'row level security' or 'row_security' as appropriate.
Happy Thanksgiving!
2014-11-27 07:06:36 +01:00
|
|
|
char *polroles;
|
|
|
|
char *polqual;
|
|
|
|
char *polwithcheck;
|
|
|
|
} PolicyInfo;
|
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
|
|
|
|
2017-01-19 18:00:00 +01:00
|
|
|
/*
|
|
|
|
* The PublicationInfo struct is used to represent publications.
|
|
|
|
*/
|
|
|
|
typedef struct _PublicationInfo
|
|
|
|
{
|
|
|
|
DumpableObject dobj;
|
2021-12-31 17:39:26 +01:00
|
|
|
const char *rolname;
|
2017-01-19 18:00:00 +01:00
|
|
|
bool puballtables;
|
|
|
|
bool pubinsert;
|
|
|
|
bool pubupdate;
|
|
|
|
bool pubdelete;
|
2018-04-07 17:24:53 +02:00
|
|
|
bool pubtruncate;
|
2020-04-08 09:59:27 +02:00
|
|
|
bool pubviaroot;
|
2017-01-19 18:00:00 +01:00
|
|
|
} PublicationInfo;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The PublicationRelInfo struct is used to represent publication table
|
|
|
|
* mapping.
|
|
|
|
*/
|
|
|
|
typedef struct _PublicationRelInfo
|
|
|
|
{
|
|
|
|
DumpableObject dobj;
|
2021-01-14 22:19:38 +01:00
|
|
|
PublicationInfo *publication;
|
2017-01-19 18:00:00 +01:00
|
|
|
TableInfo *pubtable;
|
Allow specifying row filters for logical replication of tables.
This feature adds row filtering for publication tables. When a publication
is defined or modified, an optional WHERE clause can be specified. Rows
that don't satisfy this WHERE clause will be filtered out. This allows a
set of tables to be partially replicated. The row filter is per table. A
new row filter can be added simply by specifying a WHERE clause after the
table name. The WHERE clause must be enclosed by parentheses.
The row filter WHERE clause for a table added to a publication that
publishes UPDATE and/or DELETE operations must contain only columns that
are covered by REPLICA IDENTITY. The row filter WHERE clause for a table
added to a publication that publishes INSERT can use any column. If the
row filter evaluates to NULL, it is regarded as "false". The WHERE clause
only allows simple expressions that don't have user-defined functions,
user-defined operators, user-defined types, user-defined collations,
non-immutable built-in functions, or references to system columns. These
restrictions could be addressed in the future.
If you choose to do the initial table synchronization, only data that
satisfies the row filters is copied to the subscriber. If the subscription
has several publications in which a table has been published with
different WHERE clauses, rows that satisfy ANY of the expressions will be
copied. If a subscriber is a pre-15 version, the initial table
synchronization won't use row filters even if they are defined in the
publisher.
The row filters are applied before publishing the changes. If the
subscription has several publications in which the same table has been
published with different filters (for the same publish operation), those
expressions get OR'ed together so that rows satisfying any of the
expressions will be replicated.
This means all the other filters become redundant if (a) one of the
publications have no filter at all, (b) one of the publications was
created using FOR ALL TABLES, (c) one of the publications was created
using FOR ALL TABLES IN SCHEMA and the table belongs to that same schema.
If your publication contains a partitioned table, the publication
parameter publish_via_partition_root determines if it uses the partition's
row filter (if the parameter is false, the default) or the root
partitioned table's row filter.
Psql commands \dRp+ and \d <table-name> will display any row filters.
Author: Hou Zhijie, Euler Taveira, Peter Smith, Ajin Cherian
Reviewed-by: Greg Nancarrow, Haiying Tang, Amit Kapila, Tomas Vondra, Dilip Kumar, Vignesh C, Alvaro Herrera, Andres Freund, Wei Wang
Discussion: https://www.postgresql.org/message-id/flat/CAHE3wggb715X%2BmK_DitLXF25B%3DjE6xyNCH4YOwM860JR7HarGQ%40mail.gmail.com
2022-02-22 03:24:12 +01:00
|
|
|
char *pubrelqual;
|
Allow specifying column lists for logical replication
This allows specifying an optional column list when adding a table to
logical replication. The column list may be specified after the table
name, enclosed in parentheses. Columns not included in this list are not
sent to the subscriber, allowing the schema on the subscriber to be a
subset of the publisher schema.
For UPDATE/DELETE publications, the column list needs to cover all
REPLICA IDENTITY columns. For INSERT publications, the column list is
arbitrary and may omit some REPLICA IDENTITY columns. Furthermore, if
the table uses REPLICA IDENTITY FULL, column list is not allowed.
The column list can contain only simple column references. Complex
expressions, function calls etc. are not allowed. This restriction could
be relaxed in the future.
During the initial table synchronization, only columns included in the
column list are copied to the subscriber. If the subscription has
several publications, containing the same table with different column
lists, columns specified in any of the lists will be copied.
This means all columns are replicated if the table has no column list
at all (which is treated as column list with all columns), or when of
the publications is defined as FOR ALL TABLES (possibly IN SCHEMA that
matches the schema of the table).
For partitioned tables, publish_via_partition_root determines whether
the column list for the root or the leaf relation will be used. If the
parameter is 'false' (the default), the list defined for the leaf
relation is used. Otherwise, the column list for the root partition
will be used.
Psql commands \dRp+ and \d <table-name> now display any column lists.
Author: Tomas Vondra, Alvaro Herrera, Rahila Syed
Reviewed-by: Peter Eisentraut, Alvaro Herrera, Vignesh C, Ibrar Ahmed,
Amit Kapila, Hou zj, Peter Smith, Wang wei, Tang, Shi yu
Discussion: https://postgr.es/m/CAH2L28vddB_NFdRVpuyRBJEBWjz4BSyTB=_ektNRH8NJ1jf95g@mail.gmail.com
2022-03-26 00:45:21 +01:00
|
|
|
char *pubrattrs;
|
2017-01-19 18:00:00 +01:00
|
|
|
} PublicationRelInfo;
|
|
|
|
|
Allow publishing the tables of schema.
A new option "FOR ALL TABLES IN SCHEMA" in Create/Alter Publication allows
one or more schemas to be specified, whose tables are selected by the
publisher for sending the data to the subscriber.
The new syntax allows specifying both the tables and schemas. For example:
CREATE PUBLICATION pub1 FOR TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
OR
ALTER PUBLICATION pub1 ADD TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
A new system table "pg_publication_namespace" has been added, to maintain
the schemas that the user wants to publish through the publication.
Modified the output plugin (pgoutput) to publish the changes if the
relation is part of schema publication.
Updates pg_dump to identify and dump schema publications. Updates the \d
family of commands to display schema publications and \dRp+ variant will
now display associated schemas if any.
Author: Vignesh C, Hou Zhijie, Amit Kapila
Syntax-Suggested-by: Tom Lane, Alvaro Herrera
Reviewed-by: Greg Nancarrow, Masahiko Sawada, Hou Zhijie, Amit Kapila, Haiying Tang, Ajin Cherian, Rahila Syed, Bharath Rupireddy, Mark Dilger
Tested-by: Haiying Tang
Discussion: https://www.postgresql.org/message-id/CALDaNm0OANxuJ6RXqwZsM1MSY4s19nuH3734j4a72etDwvBETQ@mail.gmail.com
2021-10-27 04:14:52 +02:00
|
|
|
/*
|
|
|
|
* The PublicationSchemaInfo struct is used to represent publication schema
|
|
|
|
* mapping.
|
|
|
|
*/
|
|
|
|
typedef struct _PublicationSchemaInfo
|
|
|
|
{
|
|
|
|
DumpableObject dobj;
|
|
|
|
PublicationInfo *publication;
|
|
|
|
NamespaceInfo *pubschema;
|
|
|
|
} PublicationSchemaInfo;
|
|
|
|
|
2017-01-19 18:00:00 +01:00
|
|
|
/*
|
|
|
|
* The SubscriptionInfo struct is used to represent subscription.
|
|
|
|
*/
|
|
|
|
typedef struct _SubscriptionInfo
|
|
|
|
{
|
|
|
|
DumpableObject dobj;
|
2021-12-31 17:39:26 +01:00
|
|
|
const char *rolname;
|
Allow upgrades to preserve the full subscription's state.
This feature will allow us to replicate the changes on subscriber nodes
after the upgrade.
Previously, only the subscription metadata information was preserved.
Without the list of relations and their state, it's not possible to
re-enable the subscriptions without missing some records as the list of
relations can only be refreshed after enabling the subscription (and
therefore starting the apply worker). Even if we added a way to refresh
the subscription while enabling a publication, we still wouldn't know
which relations are new on the publication side, and therefore should be
fully synced, and which shouldn't.
To preserve the subscription relations, this patch teaches pg_dump to
restore the content of pg_subscription_rel from the old cluster by using
binary_upgrade_add_sub_rel_state SQL function. This is supported only
in binary upgrade mode.
The subscription's replication origin is needed to ensure that we don't
replicate anything twice.
To preserve the replication origins, this patch teaches pg_dump to update
the replication origin along with creating a subscription by using
binary_upgrade_replorigin_advance SQL function to restore the
underlying replication origin remote LSN. This is supported only in
binary upgrade mode.
pg_upgrade will check that all the subscription relations are in 'i'
(init) or in 'r' (ready) state and will error out if that's not the case,
logging the reason for the failure. This helps to avoid the risk of any
dangling slot or origin after the upgrade.
Author: Vignesh C, Julien Rouhaud, Shlok Kyal
Reviewed-by: Peter Smith, Masahiko Sawada, Michael Paquier, Amit Kapila, Hayato Kuroda
Discussion: https://postgr.es/m/20230217075433.u5mjly4d5cr4hcfe@jrouhaud
2024-01-02 03:38:46 +01:00
|
|
|
char *subenabled;
|
2020-07-18 18:44:51 +02:00
|
|
|
char *subbinary;
|
Add support for streaming to built-in logical replication.
To add support for streaming of in-progress transactions into the
built-in logical replication, we need to do three things:
* Extend the logical replication protocol, so identify in-progress
transactions, and allow adding additional bits of information (e.g.
XID of subtransactions).
* Modify the output plugin (pgoutput) to implement the new stream
API callbacks, by leveraging the extended replication protocol.
* Modify the replication apply worker, to properly handle streamed
in-progress transaction by spilling the data to disk and then
replaying them on commit.
We however must explicitly disable streaming replication during
replication slot creation, even if the plugin supports it. We
don't need to replicate the changes accumulated during this phase,
and moreover we don't have a replication connection open so we
don't have where to send the data anyway.
Author: Tomas Vondra, Dilip Kumar and Amit Kapila
Reviewed-by: Amit Kapila, Kuntal Ghosh and Ajin Cherian
Tested-by: Neha Sharma, Mahendra Singh Thalor and Ajin Cherian
Discussion: https://postgr.es/m/688b0b7f-2f6c-d827-c27b-216a8e3ea700@2ndquadrant.com
2020-09-03 04:24:07 +02:00
|
|
|
char *substream;
|
Add support for prepared transactions to built-in logical replication.
To add support for streaming transactions at prepare time into the
built-in logical replication, we need to do the following things:
* Modify the output plugin (pgoutput) to implement the new two-phase API
callbacks, by leveraging the extended replication protocol.
* Modify the replication apply worker, to properly handle two-phase
transactions by replaying them on prepare.
* Add a new SUBSCRIPTION option "two_phase" to allow users to enable
two-phase transactions. We enable the two_phase once the initial data sync
is over.
We however must explicitly disable replication of two-phase transactions
during replication slot creation, even if the plugin supports it. We
don't need to replicate the changes accumulated during this phase,
and moreover, we don't have a replication connection open so we don't know
where to send the data anyway.
The streaming option is not allowed with this new two_phase option. This
can be done as a separate patch.
We don't allow to toggle two_phase option of a subscription because it can
lead to an inconsistent replica. For the same reason, we don't allow to
refresh the publication once the two_phase is enabled for a subscription
unless copy_data option is false.
Author: Peter Smith, Ajin Cherian and Amit Kapila based on previous work by Nikhil Sontakke and Stas Kelvich
Reviewed-by: Amit Kapila, Sawada Masahiko, Vignesh C, Dilip Kumar, Takamichi Osumi, Greg Nancarrow
Tested-By: Haiying Tang
Discussion: https://postgr.es/m/02DA5F5E-CECE-4D9C-8B4B-418077E2C010@postgrespro.ru
Discussion: https://postgr.es/m/CAA4eK1+opiV4aFTmWWUF9h_32=HfPOW9vZASHarT0UA5oBrtGw@mail.gmail.com
2021-07-14 04:03:50 +02:00
|
|
|
char *subtwophasestate;
|
Optionally disable subscriptions on error.
Logical replication apply workers for a subscription can easily get stuck
in an infinite loop of attempting to apply a change, triggering an error
(such as a constraint violation), exiting with the error written to the
subscription server log, and restarting.
To partially remedy the situation, this patch adds a new subscription
option named 'disable_on_error'. To be consistent with old behavior, this
option defaults to false. When true, both the tablesync worker and apply
worker catch any errors thrown and disable the subscription in order to
break the loop. The error is still also written in the logs.
Once the subscription is disabled, users can either manually resolve the
conflict/error or skip the conflicting transaction by using
pg_replication_origin_advance() function. After resolving the conflict,
users need to enable the subscription to allow apply process to proceed.
Author: Osumi Takamichi and Mark Dilger
Reviewed-by: Greg Nancarrow, Vignesh C, Amit Kapila, Wang wei, Tang Haiying, Peter Smith, Masahiko Sawada, Shi Yu
Discussion : https://postgr.es/m/DB35438F-9356-4841-89A0-412709EBD3AB%40enterprisedb.com
2022-03-14 05:02:40 +01:00
|
|
|
char *subdisableonerr;
|
2023-10-29 17:56:24 +01:00
|
|
|
char *subpasswordrequired;
|
|
|
|
char *subrunasowner;
|
|
|
|
char *subconninfo;
|
|
|
|
char *subslotname;
|
2017-04-14 19:58:46 +02:00
|
|
|
char *subsynccommit;
|
2017-01-19 18:00:00 +01:00
|
|
|
char *subpublications;
|
2023-10-29 17:56:24 +01:00
|
|
|
char *suborigin;
|
Allow upgrades to preserve the full subscription's state.
This feature will allow us to replicate the changes on subscriber nodes
after the upgrade.
Previously, only the subscription metadata information was preserved.
Without the list of relations and their state, it's not possible to
re-enable the subscriptions without missing some records as the list of
relations can only be refreshed after enabling the subscription (and
therefore starting the apply worker). Even if we added a way to refresh
the subscription while enabling a publication, we still wouldn't know
which relations are new on the publication side, and therefore should be
fully synced, and which shouldn't.
To preserve the subscription relations, this patch teaches pg_dump to
restore the content of pg_subscription_rel from the old cluster by using
binary_upgrade_add_sub_rel_state SQL function. This is supported only
in binary upgrade mode.
The subscription's replication origin is needed to ensure that we don't
replicate anything twice.
To preserve the replication origins, this patch teaches pg_dump to update
the replication origin along with creating a subscription by using
binary_upgrade_replorigin_advance SQL function to restore the
underlying replication origin remote LSN. This is supported only in
binary upgrade mode.
pg_upgrade will check that all the subscription relations are in 'i'
(init) or in 'r' (ready) state and will error out if that's not the case,
logging the reason for the failure. This helps to avoid the risk of any
dangling slot or origin after the upgrade.
Author: Vignesh C, Julien Rouhaud, Shlok Kyal
Reviewed-by: Peter Smith, Masahiko Sawada, Michael Paquier, Amit Kapila, Hayato Kuroda
Discussion: https://postgr.es/m/20230217075433.u5mjly4d5cr4hcfe@jrouhaud
2024-01-02 03:38:46 +01:00
|
|
|
char *suboriginremotelsn;
|
Add a failover option to subscriptions.
This commit introduces a new subscription option named 'failover', which
provides users with the ability to set the failover property of the
replication slot on the publisher when creating or altering a
subscription.
This uses the replication commands introduced by commit 7329240437 to
enable the failover option for a logical replication slot.
If the failover option is set to true, the associated replication slots
(i.e. the main slot and the table sync slots) in the upstream database are
enabled to be synchronized to the standbys. Note that the capability to
sync the replication slots will be added in subsequent commits.
Thanks to Masahiko Sawada for the design inputs.
Author: Shveta Malik, Hou Zhijie, Ajin Cherian
Reviewed-by: Peter Smith, Bertrand Drouvot, Dilip Kumar, Masahiko Sawada, Nisha Moond, Kuroda Hayato, Amit Kapila
Discussion: https://postgr.es/m/514f6f2f-6833-4539-39f1-96cd1e011f23@enterprisedb.com
2024-01-30 12:01:09 +01:00
|
|
|
char *subfailover;
|
2017-01-19 18:00:00 +01:00
|
|
|
} SubscriptionInfo;
|
|
|
|
|
Allow upgrades to preserve the full subscription's state.
This feature will allow us to replicate the changes on subscriber nodes
after the upgrade.
Previously, only the subscription metadata information was preserved.
Without the list of relations and their state, it's not possible to
re-enable the subscriptions without missing some records as the list of
relations can only be refreshed after enabling the subscription (and
therefore starting the apply worker). Even if we added a way to refresh
the subscription while enabling a publication, we still wouldn't know
which relations are new on the publication side, and therefore should be
fully synced, and which shouldn't.
To preserve the subscription relations, this patch teaches pg_dump to
restore the content of pg_subscription_rel from the old cluster by using
binary_upgrade_add_sub_rel_state SQL function. This is supported only
in binary upgrade mode.
The subscription's replication origin is needed to ensure that we don't
replicate anything twice.
To preserve the replication origins, this patch teaches pg_dump to update
the replication origin along with creating a subscription by using
binary_upgrade_replorigin_advance SQL function to restore the
underlying replication origin remote LSN. This is supported only in
binary upgrade mode.
pg_upgrade will check that all the subscription relations are in 'i'
(init) or in 'r' (ready) state and will error out if that's not the case,
logging the reason for the failure. This helps to avoid the risk of any
dangling slot or origin after the upgrade.
Author: Vignesh C, Julien Rouhaud, Shlok Kyal
Reviewed-by: Peter Smith, Masahiko Sawada, Michael Paquier, Amit Kapila, Hayato Kuroda
Discussion: https://postgr.es/m/20230217075433.u5mjly4d5cr4hcfe@jrouhaud
2024-01-02 03:38:46 +01:00
|
|
|
/*
|
|
|
|
* The SubRelInfo struct is used to represent a subscription relation.
|
|
|
|
*
|
|
|
|
* XXX Currently, the subscription tables are added to the subscription after
|
|
|
|
* enabling the subscription in binary-upgrade mode. As the apply workers will
|
|
|
|
* not be started in binary_upgrade mode the ordering of enable subscription
|
|
|
|
* does not matter. The order of adding the subscription tables to the
|
|
|
|
* subscription and enabling the subscription should be taken care of if this
|
|
|
|
* feature will be supported in a non-binary-upgrade mode in the future.
|
|
|
|
*/
|
|
|
|
typedef struct _SubRelInfo
|
|
|
|
{
|
|
|
|
DumpableObject dobj;
|
|
|
|
SubscriptionInfo *subinfo;
|
|
|
|
TableInfo *tblinfo;
|
|
|
|
char srsubstate;
|
|
|
|
char *srsublsn;
|
|
|
|
} SubRelInfo;
|
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/*
|
|
|
|
* common utility functions
|
2002-05-11 00:36:27 +02:00
|
|
|
*/
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2016-01-13 23:48:33 +01:00
|
|
|
extern TableInfo *getSchemaData(Archive *fout, int *numTablesPtr);
|
2000-09-15 06:35:16 +02:00
|
|
|
|
2003-12-06 04:00:16 +01:00
|
|
|
extern void AssignDumpId(DumpableObject *dobj);
|
|
|
|
extern DumpId createDumpId(void);
|
|
|
|
extern DumpId getMaxDumpId(void);
|
|
|
|
extern DumpableObject *findObjectByDumpId(DumpId dumpId);
|
|
|
|
extern DumpableObject *findObjectByCatalogId(CatalogId catalogId);
|
|
|
|
extern void getDumpableObjects(DumpableObject ***objs, int *numObjs);
|
|
|
|
|
|
|
|
extern void addObjectDependency(DumpableObject *dobj, DumpId refId);
|
|
|
|
extern void removeObjectDependency(DumpableObject *dobj, DumpId refId);
|
|
|
|
|
|
|
|
extern TableInfo *findTableByOid(Oid oid);
|
|
|
|
extern TypeInfo *findTypeByOid(Oid oid);
|
|
|
|
extern FuncInfo *findFuncByOid(Oid oid);
|
|
|
|
extern OprInfo *findOprByOid(Oid oid);
|
2011-03-10 23:30:18 +01:00
|
|
|
extern CollInfo *findCollationByOid(Oid oid);
|
2012-05-25 20:35:37 +02:00
|
|
|
extern NamespaceInfo *findNamespaceByOid(Oid oid);
|
Handle extension members when first setting object dump flags in pg_dump.
pg_dump's original approach to handling extension member objects was to
run around and clear (or set) their dump flags rather late in its data
collection process. Unfortunately, quite a lot of code expects those flags
to be valid before that; which was an entirely reasonable expectation
before we added extensions. In particular, this explains Karsten Hilbert's
recent report of pg_upgrade failing on a database in which an extension
has been installed into the pg_catalog schema. Its objects are initially
marked as not-to-be-dumped on the strength of their schema, and later we
change them to must-dump because we're doing a binary upgrade of their
extension; but we've already skipped essential tasks like making associated
DO_SHELL_TYPE objects.
To fix, collect extension membership data first, and incorporate it in the
initial setting of the dump flags, so that those are once again correct
from the get-go. This has the undesirable side effect of slightly
lengthening the time taken before pg_dump acquires table locks, but testing
suggests that the increase in that window is not very much.
Along the way, get rid of ugly special-case logic for deciding whether
to dump procedural languages, FDWs, and foreign servers; dump decisions
for those are now correct up-front, too.
In 9.3 and up, this also fixes erroneous logic about when to dump event
triggers (basically, they were *always* dumped before). In 9.5 and up,
transform objects had that problem too.
Since this problem came in with extensions, back-patch to all supported
versions.
2016-01-14 00:55:27 +01:00
|
|
|
extern ExtensionInfo *findExtensionByOid(Oid oid);
|
2021-01-14 22:19:38 +01:00
|
|
|
extern PublicationInfo *findPublicationByOid(Oid oid);
|
Allow upgrades to preserve the full subscription's state.
This feature will allow us to replicate the changes on subscriber nodes
after the upgrade.
Previously, only the subscription metadata information was preserved.
Without the list of relations and their state, it's not possible to
re-enable the subscriptions without missing some records as the list of
relations can only be refreshed after enabling the subscription (and
therefore starting the apply worker). Even if we added a way to refresh
the subscription while enabling a publication, we still wouldn't know
which relations are new on the publication side, and therefore should be
fully synced, and which shouldn't.
To preserve the subscription relations, this patch teaches pg_dump to
restore the content of pg_subscription_rel from the old cluster by using
binary_upgrade_add_sub_rel_state SQL function. This is supported only
in binary upgrade mode.
The subscription's replication origin is needed to ensure that we don't
replicate anything twice.
To preserve the replication origins, this patch teaches pg_dump to update
the replication origin along with creating a subscription by using
binary_upgrade_replorigin_advance SQL function to restore the
underlying replication origin remote LSN. This is supported only in
binary upgrade mode.
pg_upgrade will check that all the subscription relations are in 'i'
(init) or in 'r' (ready) state and will error out if that's not the case,
logging the reason for the failure. This helps to avoid the risk of any
dangling slot or origin after the upgrade.
Author: Vignesh C, Julien Rouhaud, Shlok Kyal
Reviewed-by: Peter Smith, Masahiko Sawada, Michael Paquier, Amit Kapila, Hayato Kuroda
Discussion: https://postgr.es/m/20230217075433.u5mjly4d5cr4hcfe@jrouhaud
2024-01-02 03:38:46 +01:00
|
|
|
extern SubscriptionInfo *findSubscriptionByOid(Oid oid);
|
Handle extension members when first setting object dump flags in pg_dump.
pg_dump's original approach to handling extension member objects was to
run around and clear (or set) their dump flags rather late in its data
collection process. Unfortunately, quite a lot of code expects those flags
to be valid before that; which was an entirely reasonable expectation
before we added extensions. In particular, this explains Karsten Hilbert's
recent report of pg_upgrade failing on a database in which an extension
has been installed into the pg_catalog schema. Its objects are initially
marked as not-to-be-dumped on the strength of their schema, and later we
change them to must-dump because we're doing a binary upgrade of their
extension; but we've already skipped essential tasks like making associated
DO_SHELL_TYPE objects.
To fix, collect extension membership data first, and incorporate it in the
initial setting of the dump flags, so that those are once again correct
from the get-go. This has the undesirable side effect of slightly
lengthening the time taken before pg_dump acquires table locks, but testing
suggests that the increase in that window is not very much.
Along the way, get rid of ugly special-case logic for deciding whether
to dump procedural languages, FDWs, and foreign servers; dump decisions
for those are now correct up-front, too.
In 9.3 and up, this also fixes erroneous logic about when to dump event
triggers (basically, they were *always* dumped before). In 9.5 and up,
transform objects had that problem too.
Since this problem came in with extensions, back-patch to all supported
versions.
2016-01-14 00:55:27 +01:00
|
|
|
|
2021-10-22 23:19:03 +02:00
|
|
|
extern void recordExtensionMembership(CatalogId catId, ExtensionInfo *ext);
|
Handle extension members when first setting object dump flags in pg_dump.
pg_dump's original approach to handling extension member objects was to
run around and clear (or set) their dump flags rather late in its data
collection process. Unfortunately, quite a lot of code expects those flags
to be valid before that; which was an entirely reasonable expectation
before we added extensions. In particular, this explains Karsten Hilbert's
recent report of pg_upgrade failing on a database in which an extension
has been installed into the pg_catalog schema. Its objects are initially
marked as not-to-be-dumped on the strength of their schema, and later we
change them to must-dump because we're doing a binary upgrade of their
extension; but we've already skipped essential tasks like making associated
DO_SHELL_TYPE objects.
To fix, collect extension membership data first, and incorporate it in the
initial setting of the dump flags, so that those are once again correct
from the get-go. This has the undesirable side effect of slightly
lengthening the time taken before pg_dump acquires table locks, but testing
suggests that the increase in that window is not very much.
Along the way, get rid of ugly special-case logic for deciding whether
to dump procedural languages, FDWs, and foreign servers; dump decisions
for those are now correct up-front, too.
In 9.3 and up, this also fixes erroneous logic about when to dump event
triggers (basically, they were *always* dumped before). In 9.5 and up,
transform objects had that problem too.
Since this problem came in with extensions, back-patch to all supported
versions.
2016-01-14 00:55:27 +01:00
|
|
|
extern ExtensionInfo *findOwningExtension(CatalogId catalogId);
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2003-12-06 04:00:16 +01:00
|
|
|
extern void parseOidArray(const char *str, Oid *array, int arraysize);
|
|
|
|
|
Improve pg_dump's dependency-sorting logic to enforce section dump order.
As of 9.2, with the --section option, it is very important that the concept
of "pre data", "data", and "post data" sections of the output be honored
strictly; else a dump divided into separate sectional files might be
unrestorable. However, the dependency-sorting logic knew nothing of
sections and would happily select output orderings that didn't fit that
structure. Doing so was mostly harmless before 9.2, but now we need to be
sure it doesn't do that. To fix, create dummy objects representing the
section boundaries and add dependencies between them and all the normal
objects. (This might sound expensive but it seems to only add a percent or
two to pg_dump's runtime.)
This also fixes a problem introduced in 9.1 by the feature that allows
incomplete GROUP BY lists when a primary key is given in GROUP BY.
That means that views can depend on primary key constraints. Previously,
pg_dump would deal with that by simply emitting the primary key constraint
before the view definition (and hence before the data section of the
output). That's bad enough for simple serial restores, where creating an
index before the data is loaded works, but is undesirable for speed
reasons. But it could lead to outright failure of parallel restores, as
seen in bug #6699 from Joe Van Dyk. That happened because pg_restore would
switch into parallel mode as soon as it reached the constraint, and then
very possibly would try to emit the view definition before the primary key
was committed (as a consequence of another bug that causes the view not to
be correctly marked as depending on the constraint). Adding the section
boundary constraints forces the dependency-sorting code to break the view
into separate table and rule declarations, allowing the rule, and hence the
primary key constraint it depends on, to revert to their intended location
in the post-data section. This also somewhat accidentally works around the
bogus-dependency-marking problem, because the rule will be correctly shown
as depending on the constraint, so parallel pg_restore will now do the
right thing. (We will fix the bogus-dependency problem for real in a
separate patch, but that patch is not easily back-portable to 9.1, so the
fact that this patch is enough to dodge the only known symptom is
fortunate.)
Back-patch to 9.1, except for the hunk that adds verification that the
finished archive TOC list is in correct section order; the place where
it was convenient to add that doesn't exist in 9.1.
2012-06-26 03:19:10 +02:00
|
|
|
extern void sortDumpableObjects(DumpableObject **objs, int numObjs,
|
|
|
|
DumpId preBoundaryId, DumpId postBoundaryId);
|
2004-03-03 22:28:55 +01:00
|
|
|
extern void sortDumpableObjectsByTypeName(DumpableObject **objs, int numObjs);
|
1996-07-09 08:22:35 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* version specific routines
|
|
|
|
*/
|
2012-02-06 20:07:55 +01:00
|
|
|
extern NamespaceInfo *getNamespaces(Archive *fout, int *numNamespaces);
|
2016-01-13 23:48:33 +01:00
|
|
|
extern ExtensionInfo *getExtensions(Archive *fout, int *numExtensions);
|
2012-02-06 20:07:55 +01:00
|
|
|
extern TypeInfo *getTypes(Archive *fout, int *numTypes);
|
2016-01-13 23:48:33 +01:00
|
|
|
extern FuncInfo *getFuncs(Archive *fout, int *numFuncs);
|
2022-09-23 01:41:23 +02:00
|
|
|
extern AggInfo *getAggregates(Archive *fout, int *numAggs);
|
|
|
|
extern OprInfo *getOperators(Archive *fout, int *numOprs);
|
2016-03-24 03:01:35 +01:00
|
|
|
extern AccessMethodInfo *getAccessMethods(Archive *fout, int *numAccessMethods);
|
2012-02-06 20:07:55 +01:00
|
|
|
extern OpclassInfo *getOpclasses(Archive *fout, int *numOpclasses);
|
|
|
|
extern OpfamilyInfo *getOpfamilies(Archive *fout, int *numOpfamilies);
|
|
|
|
extern CollInfo *getCollations(Archive *fout, int *numCollations);
|
|
|
|
extern ConvInfo *getConversions(Archive *fout, int *numConversions);
|
2016-01-13 23:48:33 +01:00
|
|
|
extern TableInfo *getTables(Archive *fout, int *numTables);
|
2012-03-31 20:42:17 +02:00
|
|
|
extern void getOwnedSeqs(Archive *fout, TableInfo tblinfo[], int numTables);
|
2012-02-06 20:07:55 +01:00
|
|
|
extern InhInfo *getInherits(Archive *fout, int *numInherits);
|
Fix pg_dump for hash partitioning on enum columns.
Hash partitioning on an enum is problematic because the hash codes are
derived from the OIDs assigned to the enum values, which will almost
certainly be different after a dump-and-reload than they were before.
This means that some rows probably end up in different partitions than
before, causing restore to fail because of partition constraint
violations. (pg_upgrade dodges this problem by using hacks to force
the enum values to keep the same OIDs, but that's not possible nor
desirable for pg_dump.)
Users can work around that by specifying --load-via-partition-root,
but since that's a dump-time not restore-time decision, one might
find out the need for it far too late. Instead, teach pg_dump to
apply that option automatically when dealing with a partitioned
table that has hash-on-enum partitioning.
Also deal with a pre-existing issue for --load-via-partition-root
mode: in a parallel restore, we try to TRUNCATE target tables just
before loading them, in order to enable some backend optimizations.
This is bad when using --load-via-partition-root because (a) we're
likely to suffer deadlocks from restore jobs trying to restore rows
into other partitions than they came from, and (b) if we miss getting
a deadlock we might still lose data due to a TRUNCATE removing rows
from some already-completed restore job.
The fix for this is conceptually simple: just don't TRUNCATE if we're
dealing with a --load-via-partition-root case. The tricky bit is for
pg_restore to identify those cases. In dumps using COPY commands we
can inspect each COPY command to see if it targets the nominal target
table or some ancestor. However, in dumps using INSERT commands it's
pretty impractical to examine the INSERTs in advance. To provide a
solution for that going forward, modify pg_dump to mark TABLE DATA
items that are using --load-via-partition-root with a comment.
(This change also responds to a complaint from Robert Haas that
the dump output for --load-via-partition-root is pretty confusing.)
pg_restore checks for the special comment as well as checking the
COPY command if present. This will fail to identify the combination
of --load-via-partition-root and --inserts in pre-existing dump files,
but that should be a pretty rare case in the field. If it does
happen you will probably get a deadlock failure that you can work
around by not using parallel restore, which is the same as before
this bug fix.
Having done this, there seems no remaining reason for the alarmism
in the pg_dump man page about combining --load-via-partition-root
with parallel restore, so remove that warning.
Patch by me; thanks to Julien Rouhaud for review. Back-patch to
v11 where hash partitioning was introduced.
Discussion: https://postgr.es/m/1376149.1675268279@sss.pgh.pa.us
2023-03-17 18:31:40 +01:00
|
|
|
extern void getPartitioningInfo(Archive *fout);
|
2012-02-06 20:07:55 +01:00
|
|
|
extern void getIndexes(Archive *fout, TableInfo tblinfo[], int numTables);
|
Fix assorted errors in pg_dump's handling of extended statistics objects.
pg_dump supposed that a stats object necessarily shares the same schema
as its underlying table, and that it doesn't have a separate owner.
These things may have been true during early development of the feature,
but they are not true as of v10 release.
Failure to track the object's schema separately turns out to have only
limited consequences, because pg_get_statisticsobjdef() always schema-
qualifies the target object name in the generated CREATE STATISTICS command
(a decision out of step with the rest of ruleutils.c, but I digress).
Therefore the restored object would be in the right schema, so that the
only problem is that the TOC entry would be mislabeled as to schema. That
could lead to wrong decisions for schema-selective restores, for example.
The ownership issue is a bit more serious: not only was the TOC entry
potentially mislabeled as to owner, but pg_dump didn't bother to issue an
ALTER OWNER command at all, so that after restore the stats object would
continue to be owned by the restoring superuser.
A final point is that decisions as to whether to dump a stats object or
not were driven by whether the underlying table was dumped or not. While
that's not wrong on its face, it won't scale nicely to the planned future
extension to cross-table statistics. Moreover, that design decision comes
out of the view of stats objects as being auxiliary to a particular table,
like a rule or trigger, which is exactly where the above problems came
from. Since we're now treating stats objects more like independent objects
in their own right, they ought to behave like standalone objects for this
purpose too. So change to using the generic selectDumpableObject() logic
for them (which presently amounts to "dump if containing schema is to be
dumped").
Along the way to fixing this, restructure so that getExtendedStatistics
collects the identity info (only) for all extended stats objects in one
query, and then for each object actually being dumped, we retrieve the
definition in dumpStatisticsExt. This is necessary to ensure that
schema-qualification in the generated CREATE STATISTICS command happens
with respect to the search path that pg_dump will now be using at restore
time (ie, the schema the stats object is in, not that of the underlying
table). It's probably also significantly faster in the typical scenario
where only a minority of tables have extended stats.
Back-patch to v10 where extended stats were introduced.
Discussion: https://postgr.es/m/18272.1518328606@sss.pgh.pa.us
2018-02-11 19:24:15 +01:00
|
|
|
extern void getExtendedStatistics(Archive *fout);
|
2012-02-06 20:07:55 +01:00
|
|
|
extern void getConstraints(Archive *fout, TableInfo tblinfo[], int numTables);
|
|
|
|
extern RuleInfo *getRules(Archive *fout, int *numRules);
|
|
|
|
extern void getTriggers(Archive *fout, TableInfo tblinfo[], int numTables);
|
|
|
|
extern ProcLangInfo *getProcLangs(Archive *fout, int *numProcLangs);
|
2016-01-13 23:48:33 +01:00
|
|
|
extern CastInfo *getCasts(Archive *fout, int *numCasts);
|
2015-04-26 16:33:14 +02:00
|
|
|
extern TransformInfo *getTransforms(Archive *fout, int *numTransforms);
|
2022-09-23 01:41:23 +02:00
|
|
|
extern void getTableAttrs(Archive *fout, TableInfo *tblinfo, int numTables);
|
2021-02-10 13:08:13 +01:00
|
|
|
extern bool shouldPrintColumn(const DumpOptions *dopt, const TableInfo *tbinfo, int colno);
|
2012-02-06 20:07:55 +01:00
|
|
|
extern TSParserInfo *getTSParsers(Archive *fout, int *numTSParsers);
|
|
|
|
extern TSDictInfo *getTSDictionaries(Archive *fout, int *numTSDicts);
|
|
|
|
extern TSTemplateInfo *getTSTemplates(Archive *fout, int *numTSTemplates);
|
|
|
|
extern TSConfigInfo *getTSConfigurations(Archive *fout, int *numTSConfigs);
|
|
|
|
extern FdwInfo *getForeignDataWrappers(Archive *fout,
|
|
|
|
int *numForeignDataWrappers);
|
|
|
|
extern ForeignServerInfo *getForeignServers(Archive *fout,
|
|
|
|
int *numForeignServers);
|
2016-01-13 23:48:33 +01:00
|
|
|
extern DefaultACLInfo *getDefaultACLs(Archive *fout, int *numDefaultACLs);
|
|
|
|
extern void getExtensionMembership(Archive *fout, ExtensionInfo extinfo[],
|
2012-02-06 20:07:55 +01:00
|
|
|
int numExtensions);
|
Handle extension members when first setting object dump flags in pg_dump.
pg_dump's original approach to handling extension member objects was to
run around and clear (or set) their dump flags rather late in its data
collection process. Unfortunately, quite a lot of code expects those flags
to be valid before that; which was an entirely reasonable expectation
before we added extensions. In particular, this explains Karsten Hilbert's
recent report of pg_upgrade failing on a database in which an extension
has been installed into the pg_catalog schema. Its objects are initially
marked as not-to-be-dumped on the strength of their schema, and later we
change them to must-dump because we're doing a binary upgrade of their
extension; but we've already skipped essential tasks like making associated
DO_SHELL_TYPE objects.
To fix, collect extension membership data first, and incorporate it in the
initial setting of the dump flags, so that those are once again correct
from the get-go. This has the undesirable side effect of slightly
lengthening the time taken before pg_dump acquires table locks, but testing
suggests that the increase in that window is not very much.
Along the way, get rid of ugly special-case logic for deciding whether
to dump procedural languages, FDWs, and foreign servers; dump decisions
for those are now correct up-front, too.
In 9.3 and up, this also fixes erroneous logic about when to dump event
triggers (basically, they were *always* dumped before). In 9.5 and up,
transform objects had that problem too.
Since this problem came in with extensions, back-patch to all supported
versions.
2016-01-14 00:55:27 +01:00
|
|
|
extern void processExtensionTables(Archive *fout, ExtensionInfo extinfo[],
|
|
|
|
int numExtensions);
|
2012-07-18 16:16:16 +02:00
|
|
|
extern EventTriggerInfo *getEventTriggers(Archive *fout, int *numEventTriggers);
|
Rename pg_rowsecurity -> pg_policy and other fixes
As pointed out by Robert, we should really have named pg_rowsecurity
pg_policy, as the objects stored in that catalog are policies. This
patch fixes that and updates the column names to start with 'pol' to
match the new catalog name.
The security consideration for COPY with row level security, also
pointed out by Robert, has also been addressed by remembering and
re-checking the OID of the relation initially referenced during COPY
processing, to make sure it hasn't changed under us by the time we
finish planning out the query which has been built.
Robert and Alvaro also commented on missing OCLASS and OBJECT entries
for POLICY (formerly ROWSECURITY or POLICY, depending) in various
places. This patch fixes that too, which also happens to add the
ability to COMMENT on policies.
In passing, attempt to improve the consistency of messages, comments,
and documentation as well. This removes various incarnations of
'row-security', 'row-level security', 'Row-security', etc, in favor
of 'policy', 'row level security' or 'row_security' as appropriate.
Happy Thanksgiving!
2014-11-27 07:06:36 +01:00
|
|
|
extern void getPolicies(Archive *fout, TableInfo tblinfo[], int numTables);
|
2021-01-14 22:19:38 +01:00
|
|
|
extern PublicationInfo *getPublications(Archive *fout,
|
|
|
|
int *numPublications);
|
Allow publishing the tables of schema.
A new option "FOR ALL TABLES IN SCHEMA" in Create/Alter Publication allows
one or more schemas to be specified, whose tables are selected by the
publisher for sending the data to the subscriber.
The new syntax allows specifying both the tables and schemas. For example:
CREATE PUBLICATION pub1 FOR TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
OR
ALTER PUBLICATION pub1 ADD TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
A new system table "pg_publication_namespace" has been added, to maintain
the schemas that the user wants to publish through the publication.
Modified the output plugin (pgoutput) to publish the changes if the
relation is part of schema publication.
Updates pg_dump to identify and dump schema publications. Updates the \d
family of commands to display schema publications and \dRp+ variant will
now display associated schemas if any.
Author: Vignesh C, Hou Zhijie, Amit Kapila
Syntax-Suggested-by: Tom Lane, Alvaro Herrera
Reviewed-by: Greg Nancarrow, Masahiko Sawada, Hou Zhijie, Amit Kapila, Haiying Tang, Ajin Cherian, Rahila Syed, Bharath Rupireddy, Mark Dilger
Tested-by: Haiying Tang
Discussion: https://www.postgresql.org/message-id/CALDaNm0OANxuJ6RXqwZsM1MSY4s19nuH3734j4a72etDwvBETQ@mail.gmail.com
2021-10-27 04:14:52 +02:00
|
|
|
extern void getPublicationNamespaces(Archive *fout);
|
2017-01-19 18:00:00 +01:00
|
|
|
extern void getPublicationTables(Archive *fout, TableInfo tblinfo[],
|
|
|
|
int numTables);
|
|
|
|
extern void getSubscriptions(Archive *fout);
|
Allow upgrades to preserve the full subscription's state.
This feature will allow us to replicate the changes on subscriber nodes
after the upgrade.
Previously, only the subscription metadata information was preserved.
Without the list of relations and their state, it's not possible to
re-enable the subscriptions without missing some records as the list of
relations can only be refreshed after enabling the subscription (and
therefore starting the apply worker). Even if we added a way to refresh
the subscription while enabling a publication, we still wouldn't know
which relations are new on the publication side, and therefore should be
fully synced, and which shouldn't.
To preserve the subscription relations, this patch teaches pg_dump to
restore the content of pg_subscription_rel from the old cluster by using
binary_upgrade_add_sub_rel_state SQL function. This is supported only
in binary upgrade mode.
The subscription's replication origin is needed to ensure that we don't
replicate anything twice.
To preserve the replication origins, this patch teaches pg_dump to update
the replication origin along with creating a subscription by using
binary_upgrade_replorigin_advance SQL function to restore the
underlying replication origin remote LSN. This is supported only in
binary upgrade mode.
pg_upgrade will check that all the subscription relations are in 'i'
(init) or in 'r' (ready) state and will error out if that's not the case,
logging the reason for the failure. This helps to avoid the risk of any
dangling slot or origin after the upgrade.
Author: Vignesh C, Julien Rouhaud, Shlok Kyal
Reviewed-by: Peter Smith, Masahiko Sawada, Michael Paquier, Amit Kapila, Hayato Kuroda
Discussion: https://postgr.es/m/20230217075433.u5mjly4d5cr4hcfe@jrouhaud
2024-01-02 03:38:46 +01:00
|
|
|
extern void getSubscriptionTables(Archive *fout);
|
2001-10-28 07:26:15 +01:00
|
|
|
|
1999-10-23 05:13:33 +02:00
|
|
|
#endif /* PG_DUMP_H */
|