| From: | Peter Geoghegan <pg(at)heroku(dot)com> | 
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
| Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> | 
| Subject: | Re: tuplesort.c's copytup_index() is dead code | 
| Date: | 2016-06-24 03:15:01 | 
| Message-ID: | CAM3SWZSW+59SWCm7WTXFYc=O9yJdO3_sMJ9HqXVN2YiJK2h9-g@mail.gmail.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
On Thu, Jun 23, 2016 at 7:59 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I think this may be premature in view of bug #14210.  Even if we
> don't reinstate use of this function to fix that, I'm not really
> convinced we want to get rid of it; it seems likely to me that
> we might want it again.
Oh, yes; that involves the same commit I mentioned. I'll look into #14210.
FWIW, I think that that bug tells us a lot about hash index usage in
the field. It took many months for someone to complain about what
ought to have been a really obvious bug. Clearly, hardly anybody is
using hash indexes. I broke hash index tuplesort builds in a similar
way at one point, too. The slightest bit of regression test coverage
would have caught either bug, I believe. I think that some minimal
regression tests should be added, because evidently they are needed.
-- 
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2016-06-24 03:35:22 | Re: tuplesort.c's copytup_index() is dead code | 
| Previous Message | Justin Dearing | 2016-06-24 03:09:48 | Re: Odd behavior with domains |