Support parallel migration

[sanak]

Currently, parallel environment migration causes deadlock issue.

== 20171004054800 EnsureProperSrid: migrating =================================
-- execute("SELECT UpdateGeometrySRID('issues','geom',4326)")
   -> 0.0488s
-- execute("SELECT UpdateGeometrySRID('projects','geom',4326)")
   -> 0.0091s
-- execute("SELECT UpdateGeometrySRID('users','geom',4326)")
rake aborted!
StandardError: An error has occurred, this and all later migrations canceled:

PG::TRDeadlockDetected: ERROR:  deadlock detected
DETAIL:  Process 128 waits for AccessExclusiveLock on relation 19995 of database 16384; blocked by process 127.
Process 127 waits for AccessShareLock on relation 19949 of database 16384; blocked by process 128.
HINT:  See server log for query details.
CONTEXT:  SQL statement "ALTER TABLE public.users ALTER COLUMN geom TYPE  geometry(Geometry, 4326) USING public.ST_SetSRID(geom,4326);"
PL/pgSQL function updategeometrysrid(character varying,character varying,character varying,character varying,integer) line 80 at EXECUTE
SQL statement "SELECT public.UpdateGeometrySRID('','',$1,$2,$3)"
PL/pgSQL function updategeometrysrid(character varying,character varying,integer) line 5 at SQL statement

Changes proposed in this pull request:

• Support parallel migration by transaction guard
• CI support?
  => I thought to append bundle exec rake redmine:plugins:migration & bundle exec rake redmine:plugins:migration & wait with 2 processes at the bottom of CI, but parallel execution is a rare case, so I don't support this.

@gtt-project/maintainer

[smellman]

I think transaction will run in current code(because rollback some migrations), so I need to understand the reason why this patch work well.

[dkastl]

To me this looks fine. Maybe wrapping each into a transaction will slow down SQL commands a little bit, but for migrations this should not matter really.

So I think let's do it this way.

[sanak]

@smellman (CC: @dkastl)

I think transaction will run in current code(because rollback some migrations), so I need to understand the reason why this patch work well.

Well, the transaction purpose is not for several migrations, but for avoid simultaneousALTER COLUMN ... SQL statement execution in 1 migration. But in this case, there may be another solution, so I will take a look at it.
(I just found similar old issue in rails.)
rails/rails#22092

Also, I will share deadlock reproducible steps in our GitLab.

[dkastl]

Shall we merge this?

[sanak]

@dkastl Sorry, I forgot to check more things.
I will try to check those by the middle of next week, so please wait for a while. 🙇

[sanak]

Sorry, I am not sure whether this is appropriate solution, so I will close this PR. 🙇
(Note that I added a comment in our GitLab side, so just for your information.)