6.6. SQL Limitations #

To ensure consistency of a sharded database, Shardman imposes some restrictions on SQL commands executed.

6.6.1.  ALTER SYSTEM Limitations #

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 with USING 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 where source_table is a local table, the following limitations apply:

    • Copying without the like_option clause or with INCLUDING 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, the CREATE 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 case DROP INDEX will fail to drop the index. The recommended way to remove such index cluster-wide is to use DROP INDEX IF EXISTS command. Note that DROP INDEX CONCURRENTLY is not supported on sharded tables, so this operation should be better performed in a maintenance window.

6.6.6.  UPDATE Limitations #

  • 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 as DELETE from one partition and INSERT into another (so called target partition). If a partition where UPDATE INSERTs data, is going to be UPDATED in the same statement, an error will be raised. In practice this means that if UPDATE moves data between partitions, you should explicitly exclude target partition from updating in WHERE clause of the statement.

  • INSERT INTO table_name... ON CONFLICT [conflict_target] conflict_action [WHERE condition] command is not supported on foreign tables when conflict_target is DO UPDATE. For sharded tables it is supported if expressions in SET and WHERE 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 or FOR ALL TABLES, only local partitions will be published.

  • If you publish using FOR TABLES IN SCHEMA WITH or FOR ALL TABLES along with the publish_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 the shardman 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.

pdf