From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: indxpath.c's references to IndexOptInfo.ncolumns are all wrong, no? |
Date: | 2019-02-11 01:35:04 |
Message-ID: | CAH2-WzmcfxB-7VNLzrCmvMD-gb-4e5WEDM6jurn04m8ymHFviQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Feb 10, 2019 at 5:18 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Apparently, whoever went through indxpath.c to substitute nkeycolumns
> for ncolumns was not paying attention. As far as I can tell, the
> *only* place in there where it's correct to reference ncolumns is in
> check_index_only, where we determine which columns can be extracted from
> an index-only scan.
Ugh. Yeah, it's rather inconsistent.
> I've got mixed feelings about whether to try to fix this before
> tomorrow's wraps. The attached patch seems correct and passes
> check-world, but there's sure not a lot of margin for error now.
> Thoughts?
I think that it should be fixed in the next point release if at all
possible. The bug is a simple omission. I have a hard time imagining
how your patch could possibly destabilize things, since nkeycolumns is
already used in numerous other places in indxpath.c.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2019-02-11 01:54:23 | Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages) |
Previous Message | Tom Lane | 2019-02-11 01:22:45 | Re: dsa_allocate() faliure |