Logical replication failing due to too many sessions being opened with the database

[XiaozhouWang85]

Describe the bug
When running with log replication, if the extractor encounters array data, it will open multiple connections to Postgres in order to figure out the array data's schema. When there are large tables that contain array fields, the number of connections being opened to Postgres will cause new connections to be denied. This results in a connection timeout error.

To Reproduce
Steps to reproduce the behavior:

1. Setup the extractor to run against a large table containing array fields
2. Perform a migration in Postgres on this large table (causing a large number of records to be dumped into the transaction log)
3. Run the extractor using log replication
4. Monitor the increase in connections being opened
5. Hit connection timeout at Postgres starts rejecting new connections

Timeout error:
name=tap_postgres level=CRITICAL message=connection to server at "XXXXXX" (XXXXXX), port 5432 failed: timeout expired

Spikes in connections count when running Meltano. Behaviour is shown being turned on and off by including / excluding the table containing the array field. Session counts drop after the timeout error is hit.

Expected behavior
There should be options to allow for the array fields to be handled as string or parsed as JSON. I would be hassle to have to write a potentially have to write a UDF in a downstream platform to parse the string but this is better than a process that fails and also degrades the production database or the read replica database.

Your environment

• Version of tap: 2.1.0
• meltano:v3.3.0

Additional context
Add any other context about the problem here.