Re: Logging conflicted queries on deadlocks
От | Gregory Stark |
---|---|
Тема | Re: Logging conflicted queries on deadlocks |
Дата | |
Msg-id | 87d4pnr7u6.fsf@oxford.xeocode.com обсуждение исходный текст |
Ответ на | Re: Logging conflicted queries on deadlocks (Gregory Stark <stark@enterprisedb.com>) |
Ответы |
Re: Logging conflicted queries on deadlocks
|
Список | pgsql-patches |
"Gregory Stark" <stark@enterprisedb.com> writes: > There's no way the other transaction's timeout could fire while we're doing > this is there? Are we still holding the lw locks at this point which would > prevent that? Ah, reading the patch I see comments indicating that yes that's possible and no, we don't really care. So, ok. If the backend disappears entirely could the string be empty? Perhaps it would be safer to copy out st_activity inside the loop checking st_changecount? It is a really nice feature though. Note that there was an unrelated demand for just this info on one of the other lists just today. Thanks very much Itagaki-san! -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's On-Demand Production Tuning
В списке pgsql-patches по дате отправления: