[WIP] - Add exclusive session level advisory lock (postgres only)

[mfridman]

First pass to fix #335

• postgres only with session level advisory lock
• transaction level advisory lock not implemented, likely outside the scope of this PR

The default is no lock mode, but lock=session (cli) and goose.WithLock(...) (pkg) are now functional.

EDIT: not overly happy with this implementation because it's awkward to thread the *sql.Conn through the rest of the functions and the *Migration methods. The interface seems fine to start and can be expanded to other databases.

This implementation is functional, but it does mean the max number of connections must be greater than 1. This probably solves the most common use case, but it's not ideal.

The long-term solution is uplifting goose and implementing this properly in a major version alongside #379.

---

goose CLI:

goose ... -lock=session up

goose package:

type LockMode int

const (
	LockModeNone LockMode = iota
	LockModeAdvisorySession
	LockModeAdvisoryTransaction
)

goose.WithLock(mode LockMode)

• Need to re-use the connection, otherwise if the *sql.DB was set with db.SetMaxOpenConns(1) it'll hang
• Add tests
• Remove the retry logic
• Remove pg_advisory_unlock value check
• If adding a provider abstraction, need to add a mutex to guard the lock

[mfridman]

This connection should be re-used in the event *sql.DB was configured with a maximum of 1 open connection. Otherwise, this will block indefinitely.

[mfridman]

Will probably remove this package dep, just so happens I'm quite familiar with it.

[mfridman]

Consider removing this check, see code comment.

[mfridman]

Revisit this retry logic, see code comment.

[cassiodias]

Hello! Do you have any estimation for this feature?

[mfridman]

Hello! Do you have any estimation for this feature?

This is implemented in #493 for the /v4 refactor. I'm not sure this PR will be merged into /v3. It was more of an experiment on how this could be achieved.

I'm hoping to tag a v4.0.0-beta.1 in the next few weeks, and then a more table v4.0.0-rc.1 within the next few months.

[mfridman]

I'm not sure adding locking in the module github.com/pressly/goose/v3 is worth it. It leads to some surprising behaviour.

My comments from the description still hold, and I have not spent much time thinking about it further as I've been more occupied with getting things to work in /v4

not overly happy with this implementation because it's awkward to thread the *sql.Conn through the rest of the functions and the *Migration methods.

The long-term solution is uplifting goose and implementing this properly in a major version alongside #379.

Closing this PR in favor of adding this feature to the /v4 module.