Re: [HACKERS] putting CHECK_FOR_INTERRUPTS in
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] putting CHECK_FOR_INTERRUPTS in |
Дата | |
Msg-id | 200607300148.k6U1mUN00127@momjian.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] putting CHECK_FOR_INTERRUPTS in (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-patches |
Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: > > Are we done with the sort interrupt issue mentioned in the subject line, > > and the issue outlined below? > > I'm inclined not to apply the proposed patch (adding > CHECK_FOR_INTERRUPTS) because of the risk of memory leakage inside > qsort. OTOH you could argue that there's an unfixable risk of memory > leakage there anyway, because it's always possible that the invoked > datatype comparison routine exits with elog(ERROR) for some reason, > or even contains a CHECK_FOR_INTERRUPTS call itself. Comments? OK, we do check somewhere during sorting, I assume. I can't imagine a single qsort() call taking all that long because we do them in batches anyway. > As for the question of whether we should try to detoast sort keys before > sorting, I'd suggest adding that to TODO. Investigating whether this > would be a good idea will take more time than we have for 8.2, so it's > gonna have to wait for a future cycle. Added to TODO: * Consider detoasting keys before sorting -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
В списке pgsql-patches по дате отправления: