Fix:save points causing server to run out of resources

[davecramer]

Fixes #1407

All Submissions:

• [x ] Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?

New Feature Submissions:

1. [X ] Does your submission pass tests?
2. Does mvn checkstyle:check pass ?

Changes to Existing Features:

• [NO] Does this break existing behaviour? If so please explain.
• Have you added an explanation of what your changes do and why you'd like us to include them?
• [NO] Have you written new tests for your core changes, as applicable?
• [YES] Have you successfully run tests with your changes locally?

[AppVeyorBot]

✅ Build pgjdbc 1.0.108 completed (commit 0f0cfc14f8 by @davecramer)

[vlsi]

@davecramer , does that imply network roundtrip?

[davecramer]

I'm afraid it does. I guess this is why you wanted to do this every 1000 times instead?

[vlsi]

exactly

[davecramer]

Let me see what I can do...

[fb-datax]

After changing the check for the QUERY_SUPPRESS_BEGIN to 0 the changes fix the issue. Otherwise the savepoint is never released

[davecramer]

Sadly that doesn't pass the test suite...

[davecramer]

@vlsi so looking at this it appears we send a savepoint before commit which could be removed.

[AppVeyorBot]

✅ Build pgjdbc 1.0.109 completed (commit 24e8317379 by @davecramer)

[codecov-io]

Codecov Report

Merging #1409 into master will increase coverage by 0.05%.
The diff coverage is 62.79%.

@@             Coverage Diff              @@
##             master    #1409      +/-   ##
============================================
+ Coverage     68.71%   68.76%   +0.05%     
- Complexity     3892     3913      +21     
============================================
  Files           179      179              
  Lines         16397    16436      +39     
  Branches       2668     2676       +8     
============================================
+ Hits          11267    11303      +36     
  Misses         3881     3881              
- Partials       1249     1252       +3

[AppVeyorBot]

✅ Build pgjdbc 1.0.110 completed (commit 372829a69e by @davecramer)

[fb-datax]

This implementation breaks the whole Savepoint feature for the driver. The PGSQL documentation states "RELEASE SAVEPOINT also destroys all savepoints that were established after the named savepoint was established".

The following test demonstrates the issue:

@Test
public void testPgsqlJdbcSavepoint() throws Exception {
	
	Connection conn = TestUtil.openDB();
	
	BaseConnection baseConnection = conn.unwrap(BaseConnection.class);
	baseConnection.setAutosave(AutoSave.ALWAYS);
	baseConnection.setAutoCommit(false);
	
	TestUtil.createTable(conn, "rollbacktest", "a int, str text");
	
	int iterations = 1000;
	
	for (int i = 0; i < iterations; i++) {
		long startTime = System.nanoTime();
		
		Statement statement = conn.createStatement();
		statement.executeUpdate("insert into rollbacktest(a, str) values (" + i + ", '" + UUID.randomUUID() + "')");
		statement.close();
		
		if (i == 5) {
			Statement savePoint = conn.createStatement();
			savePoint.executeUpdate("SAVEPOINT NEW_SAVEPOINT");
			savePoint.close();
		}
		
		long timeElapsed = System.nanoTime() - startTime;
		System.out.println(i + "/" + iterations + " took " + timeElapsed / 1000000 + "ms ");
	}
	
	Statement savePoint = conn.createStatement();
	savePoint.executeUpdate("ROLLBACK TO NEW_SAVEPOINT");
	savePoint.close();
}

[davecramer]

@fb-datax good catch
So the alternative is an additional round trip per statement.

[fb-datax]

@davecramer
I think that his is the only viable solution. If there are performance concerns, what about making the cleanup optional through a jdbc connection setting?

[bokken]

What if the approach was to do the "release" /before/ creating the 1000th savepoint?
This wipes out all 1000 savepoints, but that does not really matter as we no longer want to rollback to any of those.

[davecramer]

@bokken Unfortunately releasing all of them also releases SAVEPOINTS set by setSavePoint.

[bokken]

@davecramer, could we limit to the "auto save" workflow (i.e. no manual calls to setSavePoint)? That really seems to be the problematic workflow. Where a user has auto save, and then proceeds to execute thousands of things in a single transaction.

[davecramer]

@bokken in theory, How do you propose we disable setSavePoint? Throw an exception ?

[AppVeyorBot]

❌ Build pgjdbc 1.0.111 failed (commit bc23e7cd0a by @davecramer)

[bokken]

I am not suggesting we disable setSavePoint, I am suggesting that we stop automatically releasing savepoints once setSavePoint has been explicitly called.
Having said that, perhaps the automatic release could just go back to the explicit savepoint as opposed to any automatically created savepoint.

[bokken]

And perhaps the explicit call to setSavePoint releases any/all automatic savepoints first, giving a clean baseline.

[AppVeyorBot]

❌ Build pgjdbc 1.0.120 failed (commit cf826a70c0 by @davecramer)

[AppVeyorBot]

❌ Build pgjdbc 1.0.121 failed (commit 296f436b94 by @davecramer)

[AppVeyorBot]

❌ Build pgjdbc 1.0.122 failed (commit 3d0c3f23bb by @davecramer)

[AppVeyorBot]

✅ Build pgjdbc 1.0.123 completed (commit 3003bc1473 by @davecramer)

[davecramer]

And perhaps the explicit call to setSavePoint releases any/all automatic savepoints first, giving a clean baseline.

I think this seems reasonable... I'll work on implementing this.

[AppVeyorBot]

✅ Build pgjdbc 1.0.124 completed (commit f56a2d4d85 by @davecramer)

[AppVeyorBot]

❌ Build pgjdbc 1.0.125 failed (commit 2e452067cc by @davecramer)

[AppVeyorBot]

✅ Build pgjdbc 1.0.126 completed (commit afcc9fc6ff by @davecramer)

[AppVeyorBot]

✅ Build pgjdbc 1.0.128 completed (commit 11f1b33637 by @davecramer)

[AppVeyorBot]

✅ Build pgjdbc 1.0.129 completed (commit 0f1f333f86 by @davecramer)

[AppVeyorBot]

✅ Build pgjdbc 1.0.137 completed (commit 8ca9c98001 by @davecramer)

[AppVeyorBot]

✅ Build pgjdbc 1.0.138 completed (commit 2338accbdf by @davecramer)

[vlsi]

@davecramer , As far as I can tell, you create a field, but this field seems to be unused.