After installing PostgreSQL 9.2.2 and creating my test user and database, I reconfigured my Play application.
Update project/Build.scala to include the PostgreSQL driver as a dependency. val appDependencies = Seq( jdbc, anorm, "postgresql" % "postgresql" % "9.1-901-1.jdbc4" )
Update conf/application.conf to use the PostgreSQL driver for the database named "default". db.default.driver=org.postgresql.Driver db.default.url="postgres://testuser:testpass@localhost:5432/testdb" #db.default.user=sa #db.default.password=""
When applying database evolutions, the database connection pool would be exhausted:
org.postgresql.util.PSQLException: FATAL: remaining connection slots are reserved for non-replication superuser connections
The only solution was to restart the Play application entirely as I wasn't inclined to increase the connection limit without knowing why the existing limit was being hit. Re-applying the evolution would trigger the problem again.
Per Play's JDBC settings documentation, I could adjust connection pools, but as far as I could tell, the pool size wasn't the actual issue, since PostgreSQL was configured to support more connections than Play should have been using.
In my case, the problem was due to how Play handles semicolons included in a quoted string within a DML statement (initially, I had attributed this to how JDBC itself handled semicolons). You can view the current approach to statement splitting in framework/src/play-jdbc/src/main/scala/play/api/db/evolutions/Evolutions.scala line 233. Questions about this approach can be viewed on Play's Google Group and on Play 2.0 pull request #134.
This issue causes the query to fail execution and the Evolutions code retries enough times to consume the server's available connections. As I'm inserting seed data, I removed the semicolon from the quoted string and corrected the values after the evolution was applied.
With Git, one way to do this is to create a new stable code line by branching the new feature code line. History for the old stable code line effectively disappears as there is no way to reach the old stable commits from the new branch HEAD. The history will also not show that the stable code line was recreated as it will simply inherit all history from new feature (stable becomes a named reference to the same commit as newfeature). A reset HEAD~ on the new stable branch would move you back to prior newfeature commits rather than prior stable ones (the latter being the likely intent). If you take this approach, you may want to tag the "last" stable commit before the branch was re-created. Also note that using this model, you typically have to use the --force option when pushing this change, since the latest stable commit will not be a child of the remote HEAD. Additionally, this would have caused the stable code line history to "originate" from newfeature, which is not what I wanted.
Creating a branch from newfeature initially seemed to work, but because stable was the "other" branch, it becomes the second parent commit whereas I wanted it to be the first. In this case, a reset HEAD~ leaves the working copy on a newfeature commit.
The solution is to create a merge commit with its first parent as the latest stable commit and its second parent and tree identifier from the most recent newfeature commit. I couldn't find a way to do this with the merge command, so I created a synthetic commit using some lower-level Git tools. A reset HEAD~ leaves the working copy on the previous stable commit.