We have added a new test in the PostgreSQL destination setup form to verify CREATE TEMPORARY TABLES permissions. When you set up your PostgreSQL destination, you must grant the
fivetran user permission to create temporary tables in your PostgreSQL database. To learn how, see the setup guide for your PostgreSQL implementation:
We now support logical replication on Aurora PostgreSQL versions 10.6 or later.
We now replicate empty tables in a PostgreSQL source database as empty tables in the destination.
We now support syncing the BYTEA data type from your source. In your destination, the BYTEA data type will appear as BINARY data type.
We now support partitioned tables. You will be able to see both partitioned tables and their partitions in your Fivetran dashboard.
We now create a task on your Alerts page when we encounter concurrent usage errors for your replication slot. Only one process can access the same replication slot at a time. For more details, see PostgreSQL's logical decoding documentation.
We can now use unique indexes to import tables without a primary key, making imports more efficient and reliable. This fix will be gradually rolled out over the next few weeks.
We can now use unique key constraints to import tables without a primary key, making imports more efficient and reliable. This fix will be gradually rolled out over the next few weeks.
We now require that the PostgreSQL database configuration parameter
0(the default value to disable the timeout) or is greater than
5 minute. Fivetran validates this value during the setup test.
- We can now sync single- and multidimensional JSON, JSONB, and HSTORE arrays.
- We now require that the postgres database configuration parameter 'wal_sender_timeout' is set to 0 or greater than 10 minutes. The value is validated during the setup test.
We fixed a bug that caused connectors to break when syncing Postgis Geometry/Geography objects.
We have fixed a bug in our PostgreSQL connectors which was preventing some syncs from making progress.
Previously, Postgres connectors using WAL syncs could not make progress through the WAL if all of the log events were related to tables Fivetran did not sync. For example, if you selected to sync the table
PUBLIC.MY_TABLE, and all log events were on
PUBLIC.YOUR_TABLE, Fivetran could not make progress.
Now Fivetran clears the WAL slot to the most recent LSN we examined if no rows were added, deleted, or updated in Fivetran-delivered tables.
We have clarified the wording of the rescheduled sync notification message in your Sync History.
For the following warehouses, Fivetran now drops the
primary_key field from existing tables in your warehouse if there is a
primary_key coming in from your data source:
- SQL Server
For logical replication mode, we have switched to a different logical decoding plugin that consumes significantly less disk and memory resources on the database instance.
We can now correctly parse Postgres array data types with escaped characters.