Known issues in Amazon Aurora DSQL

PDFRSS

The following list contains known issues with Amazon Aurora DSQL

• Storage limit calculation might not recognize free storage because of the DROP TABLE command. If you believe you've encountered this issue, you might contact AWS Support to request a storage limit increase.

• Aurora DSQL doesn't complete COUNT(*) operations before transaction timeout for large tables. To retrieve table row count from the system catalog, see Using systems tables and commands in Aurora DSQL.

• While you can run the CREATE INDEX command without the ASYNC option and insert data before index creation and commit the transaction, doing so might result in missing index entries. We recommend that you use the ASYNC option when you create indices. If you use CREATE INDEX, confirm that Aurora DSQL has finished creating the index before you INSERT into the table.

• Aurora DSQL doesn't currently let you run GRANT [permission] ON DATABASE. If you attempt to run that statement, Aurora DSQL returns the error message ERROR: unsupported object type in GRANT.

• Aurora DSQL doesn't let non-admin user roles to run the CREATE SCHEMA command. You can't run the GRANT [permission] on DATABASE command and grant CREATE permissions on the database. If a non-admin user role tries to create a schema, Aurora DSQL returns with the error message ERROR: permission denied for database postgres.

• Aurora DSQL doesn't support the FLUSH command. Aurora DSQL returns transaction errors to any client using the FLUSH command. For example, Aurora DSQL doesn't complete queries that use FLUSH to run pipelined queries. Most clients use the SYNC command to get results over a synchronization point, but not every client does. For example, psycopg3 driver uses FLUSH to pipeline queries. The pipelined querying mode from psycopg3 doesn't work with Aurora DSQL.

• Drivers calling PG_PREPARED_STATEMENTS might provide an inconsistent view of cached prepared statements for the cluster. You might see more than the expected number of prepared statements per connection for the same cluster and IAM role. Aurora DSQL doesn't preserve statement names that you prepare.

• Clients running on IPv4 only instances might see an incorrect error if connection establishment fails. Some PostgreSQL clients resolve a hostname to both the IPv4 and IPv6 addresses if the server supports dualstack mode and supports connecting to both addresses if the first connection fails. For example, if connecting to the IPv4 address fails because of throttling errors, clients might use IPv6 to connect. If the host doesn't support IPv6 connections, it returns a NetworkUnreachable error. However, the underlying cause of the error might be that the host doesn't support IPv6.

• After an Aurora DSQL admin user creates a new schema, it's possible that subsequent GRANT and REVOKE commands from non-admin users don't reflect for existing cluster connections. This issue can last for the maximum duration of a connection of one hour.

• In rare multi-Region linked-cluster impairment scenarios, it might take longer than expected for transaction commit availability to resume. In general, automated cluster recovery operations can result in transient concurrency control or connection errors. In most cases, you will only see the effects for a percentage of your workload. When you see these transit errors, retry your transaction or reconnect with your client.

• Some SQL clients, such as Datagrip, make expansive calls to system metadata to populate schema information. Aurora DSQL doesn't support all of this information and returns errors. This issue doesn't affect SQL query functionality, but it might affect schema display.

• Aurora DSQL doesn't support nested transactions that rely on savepoints. This impacts the PsycoPG3 driver and tools that utilize nested transactions. We recommend that you use the PsycoPG2 driver.

• You might see the error Schema Already Exists if you try to create a schema, but you recently dropped the schema in another transaction. This error occurs because of a stale catalog cache. The workaround is to disconnect and reconnect.

• Queries might fail to recognize newly created schemas and tables and incorrectly report that they don't exist. This error occurs because of a stale catalog cache. The workaround is the disconnect and reconnect.

• An obsolete search path can make it so that Aurora DSQL doesn't discover new objects. Setting a search path to a schema that doesn't exist prevents Aurora DSQL from discovering that schema if you created it in another connection. The workaround is to set the search path again after you create the schema.

• Transactions that contain a query plan with a nested loop join above a merge join can consume more memory than intended and result in an out-of-memory condition.

• Non-admin users can't create objects in the public schema. Only admin users can crete objects in the public schema. The admin user role has permissions to grant read, write, and modify access to these objects to non-admin users, but it cannot grant CREATE permissions to the public schema itself. Non-admin users must use different, user-created schemas for object creation.

• Aurora DSQL doesn't support the command ALTER ROLE [] CONNECTION LIMIT. Contact AWS support if you need a connection limit increase.

• The admin role has a set of permissions related to database management tasks. By default, these permissions don't extend to objects that other users create. The admin role can't grant or revoke permissions on these user-created objects to other users. The admin user can grant itself any other role to get the necessary permissions on these objects.

• Aurora DSQL creates the admin role with all new Aurora DSQL clusters. Currently, this role lacks permissions on objects that other users create. This limitation prevents the admin role from granting or revoking permissions on objects that the admin role didn't create.