See support ticket #165416 -- I suggested this should be submitted as a bug but the support rep disagreed and said make it a feature.  

A change to PostgreSQL connectors introduced a CREATE AGGREGATE statement -- which is intended to be rolled back, it's just a trick to trigger the appearance of change. It is meant to stop faux replication lag from growing when there's no updates to the replicated tables. However, this assumes that the fivetran user has been left with CREATE privileges on the schema, which is not best practice security for postgres.  Typically it only has this privilege if someone has NOT revoked CREATE from public ... anyone following best practices will have revoked that. We noticed this due to a recurring error in our logs about the CREATE AGGREGATE failing. 

It's a neat trick and I get why you introduced it, but you inadvertently have created a security issue that requires inappropriate permissions for the fivetran user. It just fails, but it fills up logs with errors while it does it. So now we have to choose between best practice security and noisy logs, for something which isn't strictly necessary in the first place. It would have been better to add a toggled feature that we control in config where we precreate a table that fivetran gets write access to (rather than being allowed to create its own objects). Then it could do a heartbeat in that table. 

It would be great to at least be able to turn this off in the connector config, or fivetran could easily test its own permissions and stop doing the create if it isn't allowed to anyway.  

Thanks!