3

I use datagrip to move some data from a mysql installation to another postresql-database.

That worked for 3 other tables like a charm. The next one, over 500.000 rows big, could not be imported.

I use the function "Copy Table To... (F5)".

This is the log.

16:28 Connected

16:30 user@localhost: tmp_post imported to forum_post: 1999 rows (1m 58s 206ms)

16:30 Can't save current transaction state. Check connection and database settings and try again.

For other errors like wrong data types, null data on not null columns, a very helpful log is created. But not now.

The problem is also relevant when using the database plugin for IntelliJ-based IDEs, not only DataGrip

tjati
  • 5,761
  • 4
  • 41
  • 56
  • 1
    It could be that datagrip is trying to load the data into memory before inserting it into the postgresql DB. I had a similar issue trying to copy a large table from sql server to postgresql using several "datapump" software. I ended up having to write my own "datapump" application in .NET which read the data unbuffered (row at a time) and inserted into Postgresql using NpgSQL library's bulk copy functions. – Ed Mendez Sep 04 '17 at 03:53
  • Hi! I am the product marketing manager of DataGrip. Can you please send the log to JetBrains? maxim.sobolevskiy@jetbrains.com – moscas Sep 04 '17 at 09:29
  • @moscas had same issue yesterday on the latest version of IntelliJ Ultimate. Is there a workaround? – Alexander Suraphel Aug 29 '20 at 16:32
  • @moscas looking for a walkaround, still no answer. – Chootti Sep 15 '20 at 08:05
  • Have you sent logs to us? – moscas Oct 01 '20 at 15:06

1 Answers1

0

The simplest way to solve the issue is just to add "prepareThreshold=0" to your connection string as in this answer:

jdbc:postgresql://ip:port/db_name?prepareThreshold=0

Or, for example, if you a using several settings in the connection string:

jdbc:postgresql://hostmaster.com:6432,hostsecond.com:6432/dbName?&targetServerType=master&prepareThreshold=0

It's a well-known problem when connecting to the PostgreSQL server via PgBouncer rather than a problem with IntelliJ itself. When loading massive data to the database IntelliJ splits data into chunks and loads them sequentially, each time executing the query and committing the data. By default, PostgreSQL starts using server-side prepared statements after 5 execution of a query.

The driver uses server side prepared statements by default when PreparedStatement API is used. In order to get to server-side prepare, you need to execute the query 5 times (that can be configured via prepareThreshold connection property). An internal counter keeps track of how many times the statement has been executed and when it reaches the threshold it will start to use server side prepared statements.

Probably your PgBouncer runs with transaction pooling and the latest version of PbBouncer doesn't support prepared statements with transaction pooling.

How to use prepared statements with transaction pooling?

To make prepared statements work in this mode would need PgBouncer to keep track of them internally, which it does not do. So the only way to keep using PgBouncer in this mode is to disable prepared statements in the client

You can verify that the issue is indeed because of the incorrect use of prepared statements with the pgbouncer via viewing IntelliJ log files. For that go to Help -> Show Log in Explorer, and search for "org.postgresql.util.PSQLException: ERROR: prepared statement" exception.

2022-04-08 12:32:56,484 [693272684]   WARN - j.database.dbimport.ImportHead - ERROR: prepared statement "S_3649" does not exist 
java.sql.SQLException: ERROR: prepared statement "S_3649" does not exist
  at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2440)
  at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2183)
  at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:308)
  at org.postgresql.jdbc.PgConnection.executeTransactionCommand(PgConnection.java:755)
  at org.postgresql.jdbc.PgConnection.commit(PgConnection.java:777)
Dmitry.M
  • 2,833
  • 1
  • 17
  • 30