postgresql/src/test/regress/expected/sanity_check.out

209 lines
3.6 KiB
Plaintext
Raw Normal View History

2000-01-05 18:31:08 +01:00
VACUUM;
--
-- sanity check, if we don't have indices the test will take years to
-- 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
--
-- temporarily disable fancy output, so catalog changes create less diff noise
\a\t
2000-01-05 18:31:08 +01:00
SELECT relname, relhasindex
FROM pg_class c LEFT JOIN pg_namespace n ON n.oid = relnamespace
WHERE relkind IN ('r', 'p') AND (nspname ~ '^pg_temp_') IS NOT TRUE
1997-04-06 08:07:13 +02:00
ORDER BY relname;
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
fast_emp4000|t
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
iportaltest|f
kd_point_tbl|t
line_tbl|f
log_table|f
lseg_tbl|f
main_table|f
mlparted|f
mlparted1|f
mlparted11|f
mlparted12|f
mlparted2|f
mlparted3|f
mlparted4|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
pg_init_privs|t
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
pg_pltemplate|t
pg_policy|t
pg_proc|t
pg_publication|t
pg_publication_rel|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
pg_rewrite|t
pg_seclabel|t
pg_sequence|t
pg_shdepend|t
pg_shdescription|t
pg_shseclabel|t
pg_statistic|t
pg_subscription|t
pg_tablespace|t
pg_transform|t
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_box_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
testjsonb|f
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
--
-- 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
AND indkey[0] = -2 AND indnatts = 1
AND indisunique AND indimmediate);
relname | nspname
---------+---------
(0 rows)