Add SQL comment to original lock string for PostgreSQL

[joshuaflanagan]

The PostgreSQL implementation requires translating the user-specified lock string into
a pair of 32 bit numbers, which makes the lock and unlock statements opaque in the
SQL logs.

This PR adds a SQL comment containing the original lock string. The comment will be
removed from the input by the PostgreSQL parser, but it will still show up in logs.

Example rails log before this change:

2.4.1 :001 > User.with_advisory_lock_result("my_unique_lock_name"){}
   (0.4ms)  SELECT pg_try_advisory_lock(258664313,0) AS t5e3e0f0fd108ec9b914765bb4f539780
   (0.2ms)  SELECT pg_advisory_unlock(258664313,0) AS t1dcddec5851647e514718db76f7b3217

Example rails log after this change:

2.4.1 :008 > User.with_advisory_lock_result("my_unique_lock_name"){}
   (0.3ms)  SELECT pg_try_advisory_lock(258664313,0) AS t983e4b7811f1304eed9685ceb82f93b5 /* my_unique_lock_name */
   (0.2ms)  SELECT pg_advisory_unlock(258664313,0) AS tb920893abfe53ed5418fbbbe8d8ec1d3 /* my_unique_lock_name */

[mceachen]

Thanks! Would it be more friendly/ergonomic to just use the lock string, instead of a SHA, if the string is short enough? I don't think that would affect current users. I'm happy to accept either PR.

[joshuaflanagan]

I'm not sure which SHA you are suggesting we replace.

The pg_try_advisory_lock function requires an integer, so it makes sense to continue to use the stable_hashcode of the lock name.

If you are referring to replacing the random unique_column_name with the lock name instead - I had considered that, but assumed that might cause the same AR caching issues the unique_column_name is trying to prevent, since the same value could be used repeatedly. It would also probably require even more scrubbing of the lock name to ensure a valid column identifier.

I think the SQL comment is a good enough compromise, but am open to suggestions if there is something else I'm not seeing.

[mceachen]

You're right, I was thinking of a different codepath that truncated lock strings with a sha--I'd forgotten postgres' requirement for numeric locks.

Thanks again for the PR!