| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | pgsql-hackers(at)postgresql(dot)org, "Charles Duffy" <charles(dot)duffy(at)gmail(dot)com> |
| Cc: | "Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu>, pgsql-patches(at)postgresql(dot)org |
| Subject: | Re: putting CHECK_FOR_INTERRUPTS in qsort_comparetup() |
| Date: | 2006-07-14 18:43:35 |
| Message-ID: | 3410.1152902615@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-patches |
"Charles Duffy" <charles(dot)duffy(at)gmail(dot)com> writes:
> [ CHECK_FOR_INTERRUPTS inside qsort comparison routine ]
It occurs to me that there's a nonzero risk of problems here, because if
the interrupt occurs qsort() will lose control. I'm wondering whether
there are any implementations of qsort() that allocate memory and then
release it before returning. If so, interrupting the sort would lead to
memory leaked permanently (till backend exit anyway).
We might have to just tolerate this, but if it occurs on a lot of
platforms I'd have second thoughts about applying the patch. Anyone
familiar with the internals of glibc's qsort, in particular?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2006-07-14 18:43:54 | Re: contrib promotion? |
| Previous Message | Tom Lane | 2006-07-14 18:20:58 | src/tools/pginclude considered harmful (was Re: [PATCHES] toast index entries again) |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2006-07-14 19:12:57 | Re: [HACKERS] putting CHECK_FOR_INTERRUPTS in qsort_comparetup() |
| Previous Message | Tom Lane | 2006-07-14 18:37:56 | Re: Maintenance and External Projects (try 2) |