6.6. SQL Limitations #
- 6.6.1.
ALTER SYSTEM
Limitations- 6.6.2.
ALTER TABLE
Limitations- 6.6.3.
CREATE TABLE
Limitations- 6.6.4.
DROP TABLE
Limitations- 6.6.5.
CREATE INDEX CONCURRENTLY
Limitations- 6.6.6.
UPDATE
Limitations- 6.6.7.
INSERT ON CONFLICT DO UPDATE
Limitations- 6.6.8. Limitations of Managing Global Roles
- 6.6.9.
ALTER SCHEMA
Limitations- 6.6.10.
DROP SERVER
Limitations- 6.6.11. Limitations of Using Custom Databases
- 6.6.12.
CREATE COLLATION
Limitations- 6.6.13. Logical Replication Limitations
- 6.6.14. Other Limitations
- 6.6.2.
To ensure consistency of a sharded database, Shardman imposes some restrictions on SQL commands executed.
6.6.1. ALTER SYSTEM
Limitations #
ALTER SYSTEM
is prohibited (configuration changes should be performed viashardmanctl config update
).
6.6.2. ALTER TABLE
Limitations #
ALTER TABLE
is prohibited for partitions of sharded tables.All forms of
ALTER TABLE
are prohibited for sharded or global tables except these:ALTER TABLE OWNER
is allowed. For sharded table it also changes the owner of table partitions. Only the global user can be an owner of sharded or global table.ALTER TABLE COLUMN TYPE
is allowed with limitations. You cannot alter type of sharded table column participating in sharding or partitioning key. You cannot alter type of sharded table column withUSING
clause (but for global tables it is allowed). Also, it is a user's duty for now to create and keep new type exactly equal on every cluster node.ALTER TABLE COLUMN RENAME
is allowed.Adding or dropping table-wide unique constraints and checks is allowed. For global tables dropping primary key constraint or dropping columns, participating in primary key, is forbidden.
Adding foreign keys between sharded tables is possible only when they are colocated and a foreign key references tuples that are stored in the same replication group. A foreign key between sharded tables must begin with the columns used for table partitioning in both tables. A foreign key on a global table can reference only another global table. A foreign key on a sharded table can reference a colocated sharded table or a global table.
SET
/DROP NOT NULL
is allowed.Setting storage options is allowed for global tables.
Global tables cannot inherit other tables.
ALTER COLUMN SET STATISTICS
is allowed for global and sharded tables.
6.6.3. CREATE TABLE
Limitations #
All limitations for
ALTER TABLE
apply.Using of non-builtin types (types with OIDs >= 10000) or non-base types or arrays are not allowed in 'distributed_by' columns.
Only the global user can create sharded or global table.
In a colocated table, the number and types of columns used for table partitioning must be the same as for the table to colocate with.
A temporary table cannot be created as sharded or global.
For tables created using
LIKE
source_table
wheresource_table
is a local table, the following limitations apply:Copying without the
like_option
clause or withINCLUDING INDEXES
is only supported.With
INCLUDING INDEXES
, only unique indexes and indexes supporting the primary relation key are copied.Copying indexes for columns is not supported.
EXCLUDE
constraints are not supported.Local tables used in
CREATE TABLE LIKE
statement must only have columns of base types.Partial indexes are not supported.
Standard collations are only supported.
NULLS NOT DISTINCT
constraint is not supported.
6.6.4. DROP TABLE
Limitations #
Sharded or global tables and local tables cannot be dropped in the same statement.
Partitions of a sharded table cannot be dropped.
6.6.5. CREATE INDEX CONCURRENTLY
Limitations #
CREATE INDEX CONCURRENTLY
is a non-transactional command. If a problem arises while building index on sharded or global tabe, such as network failure, deadlock or a uniqueness violation in a unique index, theCREATE INDEX CONCURRENTLY
will partially fail, but can leave behind valid or invalid indexes on Shardman cluster nodes. Also an index can be completely missing on some nodes. In the later caseDROP INDEX
will fail to drop the index. The recommended way to remove such index cluster-wide is to useDROP INDEX IF EXISTS
command. Note thatDROP INDEX CONCURRENTLY
is not supported on sharded tables, so this operation should be better performed in a maintenance window.
UPDATE
of a sharded table is executed as a series of usual UPDATEs if it doesn't move data between partitions or subpartitions. Otherwise it is executed internally asDELETE
from one partition andINSERT
into another (so called target partition). If a partition whereUPDATE
INSERTs data, is going to be UPDATED in the same statement, an error will be raised. In practice this means that ifUPDATE
moves data between partitions, you should explicitly exclude target partition from updating inWHERE
clause of the statement.
6.6.7. INSERT ON CONFLICT DO UPDATE
Limitations #
INSERT INTO
command is not supported on foreign tables when conflict_target istable_name
... ON CONFLICT [conflict_target] conflict_action [WHERE condition]DO UPDATE
. For sharded tables it is supported if expressions inSET
andWHERE
clause can be safely deparsed (currently deparsing of sqlvalue-functions, parameters and subqueries inside these clauses is not supported) and a non-partial unique index, containing only table columns (not coulmn-based expressions), corresponds to conflict_target expression. This is usually the case with table's primary key.
6.6.8. Limitations of Managing Global Roles #
Global users can be created only by user with
CREATEROLE
permission on all cluster nodes.Global roles cannot be renamed.
Global and local roles cannot be dropped in the same statement.
GRANT
to a local and global role in the same statement is prohibited.REVOKE
from a local and global role in the same statement is prohibited.
6.6.9. ALTER SCHEMA
Limitations #
Schemas containing global or sharded tables cannot be renamed. Shardman service schemas (
shardman
) cannot be renamed or dropped.
6.6.10. DROP SERVER
Limitations #
Shardman cluster servers cannot be dropped. Use Shardman tools to remove servers from the cluster.
6.6.11. Limitations of Using Custom Databases #
Custom databases are not supported. All the local custom databases can be corrupted or lost during the shardmanctl operations.
6.6.12. CREATE COLLATION
Limitations #
If you use custom collation, all servers must have same version of icu. Otherwise results of queries on sharded tables may be incorrect.
6.6.13. Logical Replication Limitations #
If you attempt to publish a table containing foreign partitions with the
publish_via_partition_root
option enabled, the operation will fail. Without this option, only the local partitions will be included in the publication.When using
FOR TABLES IN SCHEMA
orFOR ALL TABLES
, only local partitions will be published.If you publish using
FOR TABLES IN SCHEMA WITH
orFOR ALL TABLES
along with thepublish_via_partition_root
option, any tables with foreign partitions will be excluded from the publication.When executing
ALTER SUBSCRIPTION ... REFRESH PUBLICATION
, depending on changes to table partitions, tables may be added to or removed from the publication.When using
FOR ALL TABLES
, tables from theshardman
schema are excluded from the publication. However, you can still create a publication specifically for tables in this schema or for individual tables within it.
6.6.14. Other Limitations #
DROP TYPE CASCADE
is prohibited if it affects types used in global or sharded tables.Access privileges management per columns is not supported for global tables.