鎖或獨占鎖或寫鎖阻止使用者修改行或整個表。 在UPDATE和DELETE修改的行在事務的持續時間內被自動獨占鎖定。 這將阻止其他使用者更改行，直到事務被提交或回退。
使用者必須等待其他使用者當他們都嘗試修改同一行時。 如果他們修改不同的行，不需要等待。 SELECT查詢不必等待。
資料庫自動執行鎖定。 然而，在某些情況下，必須手動控制鎖定。 手動鎖定可以通過使用LOCK命令完成。 它允許指定事務的鎖型別和範圍。
LOCK命令的基本語法如下：
LOCK [ TABLE ]
name
IN
lock_mode
name：要鎖定的現有表的鎖名稱(可選模式限定)。 如果在表名之前指定了ONLY，則僅該表被鎖定 如果未指定ONLY，則表及其所有後代表(如果有)被鎖定。lock_mode：鎖模式指定此鎖與之衝突的鎖。 如果未指定鎖定模式，則使用最嚴格的存取模式ACCESS EXCLUSIVE。 可能的值是：ACCESS SHARE，ROW SHARE，ROW EXCLUSIVE，SHARE UPDATE EXCLUSIVE，SHARE，SHARE ROW EXCLUSIVE，EXCLUSIVE，ACCESS EXCLUSIVE。當兩個事務正在等待彼此完成操作時，可能會發生死鎖。 雖然PostgreSQL可以檢測到它們並使用ROLLBACK結束，但死鎖仍然可能不方便。 為了防止您的應用程式遇到此問題，請確保以這樣的方式進行設計，以使其以相同的順序鎖定物件。
PostgreSQL提供了建立具有應用程式定義含義的鎖的方法。這些稱為咨詢鎖(勸告鎖,英文為：advisory locks)。 由於系統不強制使用它，因此應用程式正確使用它們。 咨詢鎖可用於鎖定針對MVCC模型策略。
例如，咨詢鎖的常見用途是模擬所謂的「平面檔案」資料管理系統的典型的悲觀鎖定策略。 雖然儲存在表中的標誌可以用於相同的目的，但是建議鎖更快，避免了表的膨脹，並且在對談結束時被伺服器自動清除。
考慮表COMPANY有以下記錄：
testdb# select * from COMPANY;
id | name | age | address | salary
----+-------+-----+-----------+--------
1 | Paul | 32 | California| 20000
2 | Allen | 25 | Texas | 15000
3 | Teddy | 23 | Norway | 20000
4 | Mark | 25 | Rich-Mond | 65000
5 | David | 27 | Texas | 85000
6 | Kim | 22 | South-Hall| 45000
7 | James | 24 | Houston | 10000
(7 rows)
以下範例在ACCESS EXCLUSIVE模式下將COMPANY表鎖定在yiibai_db資料庫中。 LOCK語句僅在事務模式下工作：
yiibai_db=#BEGIN;
LOCK TABLE company1 IN ACCESS EXCLUSIVE MODE;
PostgreSQL上面的語句將產生以下結果：
LOCK TABLE
上述訊息表示表被鎖定，直到事務結束並完成事務，必須回滾或提交事務。