Where to download pals files

Lock Releasing & Expiration

Unlike locking systems built on cache services like Memcache and Redis, whose keys can be expired by the service, there is no faculty for expiring an advisory lock in PostgreSQL. If a client holds a lock and then sleeps/hangs for mins/hours/days, no other client will be able to get that lock until the client releases it. This actually seems like a good thing to us, if a lock is acquired, it should be kept until released.

But what about accidental failures to release the lock?

1. If a developer uses but doesn’t later call ?
2. If code inside a lock accidentally throws an exception (and .release() is not called)?
3. If the process running the application crashes or the process’ server dies?

PALs helps #1 and #2 above in a few different ways:

• Locks work as context managers. Use them as much as possible to guarantee a lock is released.
• Locks release their lock when garbage collected.
• PALs uses a dedicated SQLAlchemy connection pool. When a connection is returned to the pool, either because a connection is called or due to garbage collection of the connection, PALs issues a . It should therefore be impossible for an idle connection in the pool to ever still be holding a lock.

Regarding #3 above, is implicitly invoked by PostgreSQL whenever a connection (a.k.a session) ends, even if the client disconnects ungracefully. So if a process crashes or otherwise disappears, PostgreSQL should notice and remove all locks held by that connection/session.

The possibility could exist that PostgreSQL does not detect a connection has closed and keeps a lock open indefinitely. However, in manual testing using no way was found to end the Python process without PostgreSQL detecting it.