ล็อกคำแนะนำสำหรับการประสานงานระหว่างแอปพลิเคชัน

Advisory locks are locks whose meaning is defined entirely by your application. PostgreSQL does not associate them with any row or table — your code decides what a given lock key represents.

They are perfect for coordination that does not map to a single row:

• Ensuring only one worker runs a nightly job
• Serializing access to an external API
• Preventing two processes from importing the same file

An advisory lock is identified by a 64-bit integer, or by two 32-bit integers. You pick the numbers; a common pattern is to hash a string into an integer key.

pg_advisory_lock holds the lock until you release it or the session ends. It blocks if another session already holds the same key.

Often you do not want to wait. pg_try_advisory_lock returns true if it got the lock and false immediately if someone else holds it.

A cron-triggered job uses try-lock to ensure only one instance runs. If it returns false, this instance simply exits.

The _xact_ variants release automatically at COMMIT or ROLLBACK, so you cannot forget to unlock. Great for short critical sections.

Advisory locks show up in pg_locks with locktype 'advisory'. Use it to debug who is holding what.

Key differences from SELECT ... FOR UPDATE:

• Advisory locks are not tied to any row
• They survive across statements without holding row versions
• Their meaning is purely a convention your app agrees on

Watch out for:

• Forgetting to unlock session-level locks (prefer xact variants)
• Key collisions between unrelated features — namespace your keys
• Connection poolers reusing sessions and leaking locks

Session-level locks can be acquired multiple times and must be unlocked the same number of times. To clear everything held by the current session at once, use the unlock-all helper.

You learned advisory locks:

• Application-defined locks not tied to rows or tables
• Identified by 64-bit or paired 32-bit keys
• Session-level vs auto-releasing transaction-level variants
• pg_try_advisory_lock powers single-worker patterns
• Namespace keys and prefer xact locks to avoid leaks