Re: VACUUM FULL deadlock with backend startup
| От | Nikhil Sontakke |
|---|---|
| Тема | Re: VACUUM FULL deadlock with backend startup |
| Дата | |
| Msg-id | AANLkTikjUFoTcCvFpfS4okptBKepfhMryYgMF=8VmYXT@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: VACUUM FULL deadlock with backend startup (Robert Haas <robertmhaas@gmail.com>) |
| Ответы |
Re: VACUUM FULL deadlock with backend startup
|
| Список | pgsql-hackers |
Hi,<br /><br /> > The fix is similar to the earlier commit by Tom. I tested this fix<br /><div class="gmail_quote"><blockquoteclass="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204,204); padding-left: 1ex;"><div class="im"> > against 8.3.13. We lock the parent catalog now before calling<br /> >index_open. Patch against git HEAD attached with this mail. I guess we<br /> > will backpatch this? Tom's last commitwas backpatched till 8.2 I<br /> > think.<br /><br /></div>Is it really worth slowing down the startup sequencefor every<br /> connection to avoid deadlocking against a very rare maintenance<br /> operation?<br /><font color="#888888"><br/></font></blockquote><br /></div>Not really a performance issue AFAICS. If the relcache init file exists,then the phase2 of the catalog cache which eventually calls the above code path is avoided.<br /><br />Regards,<br/>Nikhils<br /><br />
В списке pgsql-hackers по дате отправления: