From: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: bug with expression index on partition |
Date: | 2018-06-25 02:57:41 |
Message-ID: | d03b045d-826e-1e7d-609e-967f8d80eefd@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2018/06/23 5:54, Alvaro Herrera wrote:
> On 2018-Jun-21, Amit Langote wrote:
>
>> On 2018/06/21 15:35, Amit Langote wrote:
>>> So, CompareIndexInfo and generateClonedIndexStmt are both doing the right
>>> thing, but DefineIndex is not. Attached is a patch to fix DefineIndex so
>>> that it converts indexParams before recursing to create the index on a
>>> partition.
>>
>> I noticed that while CompareIndexInfo and generateClonedIndexStmt would
>> reject the case where index expressions contain a whole-row Var, my patch
>> didn't teach to do the same to DefineIndex, causing asymmetric behavior.
>> So, whereas ATTACH PARTITION would error out when trying to clone a
>> parent's index that contains a whole-row Var, recursively creating an
>> index on partition won't.
>>
>> I updated the patch so that even DefineIndex will check if any whole-row
>> Vars were encountered during conversion and error out if so.
>
> Thanks. I pushed this version, although I tweaked the test so that this
> condition is verified in the test that is supposed to do so, rather than
> creating a whole new set of tables for this purpose. The way it would
> fail with unpatched code is perhaps less noisy that what you proposed,
> but I think it's quite enough.
Thanks. The test changes you committed seem fine.
Regards,
Amit
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2018-06-25 03:32:37 | Re: effect of JIT tuple deform? |
Previous Message | Michael Paquier | 2018-06-25 02:43:56 | Incorrect fsync handling in pg_basebackup's tar_finish |