diff options
| author | Alvaro Herrera <alvherre@alvh.no-ip.org> | 2014-03-19 15:10:36 -0300 |
|---|---|---|
| committer | Alvaro Herrera <alvherre@alvh.no-ip.org> | 2014-03-19 15:10:36 -0300 |
| commit | f88d4cfc9d417dac2ee41a8f5e593898e56fd2bd (patch) | |
| tree | 225a86782144a53e83e6083e92df29c8d0785007 /src/backend/executor/execMain.c | |
| parent | ea8c7e9054abf23fa3de2f8e4414f60ac8a8b620 (diff) | |
| download | postgresql-f88d4cfc9d417dac2ee41a8f5e593898e56fd2bd.tar.gz postgresql-f88d4cfc9d417dac2ee41a8f5e593898e56fd2bd.zip | |
Setup error context callback for transaction lock waits
With this in place, a session blocking behind another one because of
tuple locks will get a context line mentioning the relation name, tuple
TID, and operation being done on tuple. For example:
LOG: process 11367 still waiting for ShareLock on transaction 717 after 1000.108 ms
DETAIL: Process holding the lock: 11366. Wait queue: 11367.
CONTEXT: while updating tuple (0,2) in relation "foo"
STATEMENT: UPDATE foo SET value = 3;
Most usefully, the new line is displayed by log entries due to
log_lock_waits, although of course it will be printed by any other log
message as well.
Author: Christian Kruse, some tweaks by Álvaro Herrera
Reviewed-by: Amit Kapila, Andres Freund, Tom Lane, Robert Haas
Diffstat (limited to 'src/backend/executor/execMain.c')
| -rw-r--r-- | src/backend/executor/execMain.c | 4 |
1 files changed, 3 insertions, 1 deletions
diff --git a/src/backend/executor/execMain.c b/src/backend/executor/execMain.c index 9e3d879ae77..886c75125d2 100644 --- a/src/backend/executor/execMain.c +++ b/src/backend/executor/execMain.c @@ -1982,7 +1982,9 @@ EvalPlanQualFetch(EState *estate, Relation relation, int lockmode, if (TransactionIdIsValid(SnapshotDirty.xmax)) { ReleaseBuffer(buffer); - XactLockTableWait(SnapshotDirty.xmax); + XactLockTableWait(SnapshotDirty.xmax, + relation, &tuple.t_data->t_ctid, + XLTW_FetchUpdated); continue; /* loop back to repeat heap_fetch */ } |