Re: Always truncate segments before unlink
От | Fujii Masao |
---|---|
Тема | Re: Always truncate segments before unlink |
Дата | |
Msg-id | AANLkTinoP4QIwN8Ij_lFtqCpp5P_q8sj4eefQcVYmYz8@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Always truncate segments before unlink (Takahiro Itagaki <itagaki.takahiro@oss.ntt.co.jp>) |
Список | pgsql-hackers |
On Tue, Jul 6, 2010 at 9:59 AM, Takahiro Itagaki <itagaki.takahiro@oss.ntt.co.jp> wrote: > > Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Truncating seems like an ugly kluge that's not fixing the real problem. >> Why are there open descriptors for a dropped relation? They should all >> get closed as a consequence of relcache flush. > > Relcache will be flushed at the next command, but there could be some > *idle backends* kept by connection pooling. They won't close dropped files > until shared cache invalidation queue are almost filled, that might take > long time. Right. Since many connection poolers use LIFO method to manage the pooled connections, this problem is very likely to happen. > There might be another solution that we send PROCSIG_CATCHUP_INTERRUPT > signal not only on the threshold of queue length but also on timeout, > where the signal is sent when we have some old messages in the queue > longer than 30sec - 1min. REINDEX or something should not send PROCSIG_CATCHUP_INTERRUPT immediately? Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: