Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
| postgresql_management_locking [2020/01/20 12:03] – andonovj | postgresql_management_locking [2020/01/20 20:36] (current) – external edit 127.0.0.1 | ||
|---|---|---|---|
| Line 8: | Line 8: | ||
| * Table Locks | * Table Locks | ||
| * Row Locks | * Row Locks | ||
| + | * Advisory Locks | ||
| Let's start with the Table Locks | Let's start with the Table Locks | ||
| Line 44: | Line 45: | ||
| {{ : | {{ : | ||
| + | =====Advisory Locks===== | ||
| + | PostgreSQL provides a means for creating locks that have application-defined meanings. These are called advisory locks, because the system does not enforce their use — it is up to the application to use them correctly. Advisory locks can be useful for locking strategies that are an awkward fit for the MVCC model. For example, a common use of advisory locks is to emulate pessimistic locking strategies typical of so-called "flat file" data management systems. While a flag stored in a table could be used for the same purpose, advisory locks are faster, avoid table bloat, and are automatically cleaned up by the server at the end of the session. | ||
| ======Monitoring====== | ======Monitoring====== | ||