| От | Heikki Linnakangas |
|---|---|
| Тема | Re: Curious buildfarm failures |
| Дата | |
| Msg-id | 50F488B8.9070402@vmware.com обсуждение исходный текст |
| Ответ на | Re: Curious buildfarm failures (Heikki Linnakangas <hlinnakangas@vmware.com>) |
| Ответы |
Re: Curious buildfarm failures
|
| Список | pgsql-hackers |
On 15.01.2013 00:14, Heikki Linnakangas wrote: > On 14.01.2013 23:35, Tom Lane wrote: >> Since commit 2065dd2834e832eb820f1fbcd16746d6af1f6037, there have been >> a few buildfarm failures along the lines of >> >> -- Commit table drop >> COMMIT PREPARED 'regress-two'; >> ! PANIC: failed to re-find shared proclock object >> ! PANIC: failed to re-find shared proclock object >> ! connection to server was lost >> >> Evidently I bollixed something, but what? I've been unable to reproduce >> this locally so far. Anybody see what's wrong? > > I was able to reproduce this by setting max_locks_per_transaction and > max_connections to the minimum. My assumption is that there's something > wrong in the way hash_update_hash_key() handles collisions. The problem seems to be when the the old and the key hash to the same bucket. In that case, hash_update_hash_key() tries to link the entry to itself. The attached patch fixes it for me. - Heikki
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера