2000-01-05 18:31:08 +01:00
|
|
|
VACUUM;
|
|
|
|
--
|
|
|
|
-- sanity check, if we don't have indices the test will take years to
|
2006-08-06 06:35:21 +02:00
|
|
|
-- complete. But skip TOAST relations (since they will have varying
|
|
|
|
-- names depending on the current OID counter) as well as temp tables
|
|
|
|
-- of other backends (to avoid timing-dependent behavior).
|
2000-01-05 18:31:08 +01:00
|
|
|
--
|
2013-10-26 17:24:04 +02:00
|
|
|
-- temporarily disable fancy output, so catalog changes create less diff noise
|
|
|
|
\a\t
|
2000-01-05 18:31:08 +01:00
|
|
|
SELECT relname, relhasindex
|
2006-08-06 06:35:21 +02:00
|
|
|
FROM pg_class c LEFT JOIN pg_namespace n ON n.oid = relnamespace
|
|
|
|
WHERE relkind = 'r' AND (nspname ~ '^pg_temp_') IS NOT TRUE
|
1997-04-06 08:07:13 +02:00
|
|
|
ORDER BY relname;
|
2013-10-26 17:24:04 +02:00
|
|
|
a|f
|
|
|
|
a_star|f
|
|
|
|
abstime_tbl|f
|
|
|
|
aggtest|f
|
|
|
|
array_index_op_test|t
|
|
|
|
array_op_test|f
|
|
|
|
b|f
|
|
|
|
b_star|f
|
|
|
|
box_tbl|f
|
|
|
|
bprime|f
|
|
|
|
bt_f8_heap|t
|
|
|
|
bt_i4_heap|t
|
|
|
|
bt_name_heap|t
|
|
|
|
bt_txt_heap|t
|
|
|
|
c|f
|
|
|
|
c_star|f
|
|
|
|
char_tbl|f
|
|
|
|
check2_tbl|f
|
|
|
|
check_tbl|f
|
|
|
|
circle_tbl|t
|
|
|
|
city|f
|
|
|
|
copy_tbl|f
|
|
|
|
d|f
|
|
|
|
d_star|f
|
|
|
|
date_tbl|f
|
|
|
|
default_tbl|f
|
|
|
|
defaultexpr_tbl|f
|
|
|
|
dept|f
|
|
|
|
dupindexcols|t
|
|
|
|
e_star|f
|
|
|
|
emp|f
|
|
|
|
equipment_r|f
|
|
|
|
f_star|f
|
2016-04-14 05:33:31 +02:00
|
|
|
fast_emp4000|t
|
2013-10-26 17:24:04 +02:00
|
|
|
float4_tbl|f
|
|
|
|
float8_tbl|f
|
|
|
|
func_index_heap|t
|
|
|
|
hash_f8_heap|t
|
|
|
|
hash_i4_heap|t
|
|
|
|
hash_name_heap|t
|
|
|
|
hash_txt_heap|t
|
|
|
|
hobbies_r|f
|
|
|
|
ihighway|t
|
|
|
|
inet_tbl|f
|
|
|
|
inhf|f
|
|
|
|
inhx|t
|
|
|
|
insert_tbl|f
|
|
|
|
int2_tbl|f
|
|
|
|
int4_tbl|f
|
|
|
|
int8_tbl|f
|
|
|
|
interval_tbl|f
|
Fix two bugs in merging of inherited CHECK constraints.
Historically, we've allowed users to add a CHECK constraint to a child
table and then add an identical CHECK constraint to the parent. This
results in "merging" the two constraints so that the pre-existing
child constraint ends up with both conislocal = true and coninhcount > 0.
However, if you tried to do it in the other order, you got a duplicate
constraint error. This is problematic for pg_dump, which needs to issue
separated ADD CONSTRAINT commands in some cases, but has no good way to
ensure that the constraints will be added in the required order.
And it's more than a bit arbitrary, too. The goal of complaining about
duplicated ADD CONSTRAINT commands can be served if we reject the case of
adding a constraint when the existing one already has conislocal = true;
but if it has conislocal = false, let's just make the ADD CONSTRAINT set
conislocal = true. In this way, either order of adding the constraints
has the same end result.
Another problem was that the code allowed creation of a parent constraint
marked convalidated that is merged with a child constraint that is
!convalidated. In this case, an inheritance scan of the parent table could
emit some rows violating the constraint condition, which would be an
unexpected result given the marking of the parent constraint as validated.
Hence, forbid merging of constraints in this case. (Note: valid child and
not-valid parent seems fine, so continue to allow that.)
Per report from Benedikt Grundmann. Back-patch to 9.2 where we introduced
possibly-not-valid check constraints. The second bug obviously doesn't
apply before that, and I think the first doesn't either, because pg_dump
only gets into this situation when dealing with not-valid constraints.
Report: <CADbMkNPT-Jz5PRSQ4RbUASYAjocV_KHUWapR%2Bg8fNvhUAyRpxA%40mail.gmail.com>
Discussion: <22108.1475874586@sss.pgh.pa.us>
2016-10-09 01:29:27 +02:00
|
|
|
invalid_check_con|f
|
|
|
|
invalid_check_con_child|f
|
2013-10-26 17:24:04 +02:00
|
|
|
iportaltest|f
|
|
|
|
kd_point_tbl|t
|
|
|
|
line_tbl|f
|
|
|
|
log_table|f
|
|
|
|
lseg_tbl|f
|
|
|
|
main_table|f
|
|
|
|
money_data|f
|
|
|
|
num_data|f
|
|
|
|
num_exp_add|t
|
|
|
|
num_exp_div|t
|
|
|
|
num_exp_ln|t
|
|
|
|
num_exp_log10|t
|
|
|
|
num_exp_mul|t
|
|
|
|
num_exp_power_10_ln|t
|
|
|
|
num_exp_sqrt|t
|
|
|
|
num_exp_sub|t
|
|
|
|
num_input_test|f
|
|
|
|
num_result|f
|
|
|
|
onek|t
|
|
|
|
onek2|t
|
|
|
|
path_tbl|f
|
|
|
|
person|f
|
|
|
|
pg_aggregate|t
|
|
|
|
pg_am|t
|
|
|
|
pg_amop|t
|
|
|
|
pg_amproc|t
|
|
|
|
pg_attrdef|t
|
|
|
|
pg_attribute|t
|
|
|
|
pg_auth_members|t
|
|
|
|
pg_authid|t
|
|
|
|
pg_cast|t
|
|
|
|
pg_class|t
|
|
|
|
pg_collation|t
|
|
|
|
pg_constraint|t
|
|
|
|
pg_conversion|t
|
|
|
|
pg_database|t
|
|
|
|
pg_db_role_setting|t
|
|
|
|
pg_default_acl|t
|
|
|
|
pg_depend|t
|
|
|
|
pg_description|t
|
|
|
|
pg_enum|t
|
|
|
|
pg_event_trigger|t
|
|
|
|
pg_extension|t
|
|
|
|
pg_foreign_data_wrapper|t
|
|
|
|
pg_foreign_server|t
|
|
|
|
pg_foreign_table|t
|
|
|
|
pg_index|t
|
|
|
|
pg_inherits|t
|
2016-04-07 03:45:32 +02:00
|
|
|
pg_init_privs|t
|
2013-10-26 17:24:04 +02:00
|
|
|
pg_language|t
|
|
|
|
pg_largeobject|t
|
|
|
|
pg_largeobject_metadata|t
|
|
|
|
pg_namespace|t
|
|
|
|
pg_opclass|t
|
|
|
|
pg_operator|t
|
|
|
|
pg_opfamily|t
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
pg_partitioned_table|t
|
2013-10-26 17:24:04 +02:00
|
|
|
pg_pltemplate|t
|
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
|
|
|
pg_policy|t
|
2013-10-26 17:24:04 +02:00
|
|
|
pg_proc|t
|
|
|
|
pg_range|t
|
Introduce replication progress tracking infrastructure.
When implementing a replication solution ontop of logical decoding, two
related problems exist:
* How to safely keep track of replication progress
* How to change replication behavior, based on the origin of a row;
e.g. to avoid loops in bi-directional replication setups
The solution to these problems, as implemented here, consist out of
three parts:
1) 'replication origins', which identify nodes in a replication setup.
2) 'replication progress tracking', which remembers, for each
replication origin, how far replay has progressed in a efficient and
crash safe manner.
3) The ability to filter out changes performed on the behest of a
replication origin during logical decoding; this allows complex
replication topologies. E.g. by filtering all replayed changes out.
Most of this could also be implemented in "userspace", e.g. by inserting
additional rows contain origin information, but that ends up being much
less efficient and more complicated. We don't want to require various
replication solutions to reimplement logic for this independently. The
infrastructure is intended to be generic enough to be reusable.
This infrastructure also replaces the 'nodeid' infrastructure of commit
timestamps. It is intended to provide all the former capabilities,
except that there's only 2^16 different origins; but now they integrate
with logical decoding. Additionally more functionality is accessible via
SQL. Since the commit timestamp infrastructure has also been introduced
in 9.5 (commit 73c986add) changing the API is not a problem.
For now the number of origins for which the replication progress can be
tracked simultaneously is determined by the max_replication_slots
GUC. That GUC is not a perfect match to configure this, but there
doesn't seem to be sufficient reason to introduce a separate new one.
Bumps both catversion and wal page magic.
Author: Andres Freund, with contributions from Petr Jelinek and Craig Ringer
Reviewed-By: Heikki Linnakangas, Petr Jelinek, Robert Haas, Steve Singer
Discussion: 20150216002155.GI15326@awork2.anarazel.de,
20140923182422.GA15776@alap3.anarazel.de,
20131114172632.GE7522@alap2.anarazel.de
2015-04-29 19:30:53 +02:00
|
|
|
pg_replication_origin|t
|
2013-10-26 17:24:04 +02:00
|
|
|
pg_rewrite|t
|
|
|
|
pg_seclabel|t
|
|
|
|
pg_shdepend|t
|
|
|
|
pg_shdescription|t
|
|
|
|
pg_shseclabel|t
|
|
|
|
pg_statistic|t
|
|
|
|
pg_tablespace|t
|
2015-04-26 16:33:14 +02:00
|
|
|
pg_transform|t
|
2013-10-26 17:24:04 +02:00
|
|
|
pg_trigger|t
|
|
|
|
pg_ts_config|t
|
|
|
|
pg_ts_config_map|t
|
|
|
|
pg_ts_dict|t
|
|
|
|
pg_ts_parser|t
|
|
|
|
pg_ts_template|t
|
|
|
|
pg_type|t
|
|
|
|
pg_user_mapping|t
|
|
|
|
point_tbl|t
|
|
|
|
polygon_tbl|t
|
|
|
|
quad_point_tbl|t
|
|
|
|
radix_text_tbl|t
|
|
|
|
ramp|f
|
|
|
|
real_city|f
|
|
|
|
reltime_tbl|f
|
|
|
|
road|t
|
|
|
|
shighway|t
|
|
|
|
slow_emp4000|f
|
|
|
|
sql_features|f
|
|
|
|
sql_implementation_info|f
|
|
|
|
sql_languages|f
|
|
|
|
sql_packages|f
|
|
|
|
sql_parts|f
|
|
|
|
sql_sizing|f
|
|
|
|
sql_sizing_profiles|f
|
|
|
|
stud_emp|f
|
|
|
|
student|f
|
|
|
|
tenk1|t
|
|
|
|
tenk2|t
|
|
|
|
test_range_excl|t
|
|
|
|
test_range_gist|t
|
|
|
|
test_range_spgist|t
|
|
|
|
test_tsvector|f
|
2014-03-24 01:18:06 +01:00
|
|
|
testjsonb|f
|
2013-10-26 17:24:04 +02:00
|
|
|
text_tbl|f
|
|
|
|
time_tbl|f
|
|
|
|
timestamp_tbl|f
|
|
|
|
timestamptz_tbl|f
|
|
|
|
timetz_tbl|f
|
|
|
|
tinterval_tbl|f
|
|
|
|
varchar_tbl|f
|
|
|
|
-- restore normal output mode
|
|
|
|
\a\t
|
2002-08-10 17:54:04 +02:00
|
|
|
--
|
|
|
|
-- another sanity check: every system catalog that has OIDs should have
|
|
|
|
-- a unique index on OID. This ensures that the OIDs will be unique,
|
|
|
|
-- even after the OID counter wraps around.
|
|
|
|
-- We exclude non-system tables from the check by looking at nspname.
|
|
|
|
--
|
|
|
|
SELECT relname, nspname
|
|
|
|
FROM pg_class c LEFT JOIN pg_namespace n ON n.oid = relnamespace
|
|
|
|
WHERE relhasoids
|
|
|
|
AND ((nspname ~ '^pg_') IS NOT FALSE)
|
|
|
|
AND NOT EXISTS (SELECT 1 FROM pg_index i WHERE indrelid = c.oid
|
2009-07-29 22:56:21 +02:00
|
|
|
AND indkey[0] = -2 AND indnatts = 1
|
|
|
|
AND indisunique AND indimmediate);
|
2002-08-10 17:54:04 +02:00
|
|
|
relname | nspname
|
|
|
|
---------+---------
|
|
|
|
(0 rows)
|
|
|
|
|