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
|
|
|
|
|
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)
|
|
|
|
|
|
