| From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
|---|---|
| To: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | XactLockTableWait doesn't set wait_event correctly |
| Date: | 2016-11-29 11:26:01 |
| Message-ID: | CANP8+jJ4TXchNfea08tf5EPBNzb2VP5Of0eTcnDUkBoir6yL5w@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
New (9.4) XactLockTableWait() sets the reason for the wait, so that if
we emit a log message then it will produce a log message to say its
not waiting on a transaction, its waiting on a lock.
Nice. log_lock_waits works great.
New (9.6) wait_event code is not correctly set. In ProcSleep() we set
the wait reason according to the actual lock tag, effectively ignoring
the information specifically provided by XactLockTableWait().
Ugh.
pg_stat_activity shows a wait_event of 'transactionid' rather than 'tuple'
pg_locks shows a transactionid lock rather than a wait for tuple lock
That looks like a bug since we get different answers from
log_lock_wait and wait_event, which is annoying and confusing.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2016-11-29 11:26:07 | EvalPlanQual() doesn't follow LockTuple() pattern |
| Previous Message | Amit Kapila | 2016-11-29 11:24:57 | Re: Parallel execution and prepared statements |