Thread: GIN code managing entry insertion not able to differentiate fresh and old indexes
GIN code managing entry insertion not able to differentiate fresh and old indexes
From
Michael Paquier
Date:
Hi all, While playing with the GIN code for an upcoming patch, I noticed that when inserting a new entry in a new index, this code path is not able to make the difference if the index is in a build state or not. Basically, when entering in ginEntryInsert@gininsert.c GinBtree built via ginPrepareEntryScan does not have its flag isBuild set up properly. I think that it should be set as follows to let this code path be aware that index is in build state: btree.isBuild = (buildStats != NULL); Note that the entry insertion code does nothing with isBuild yet, so it does not really impact back-branches. However, if in the future we fix a bug in this area and need to make distinction between a fresh index and an old one well there will be problems. For those reasons, this correctness fix should be perhaps master-only for now (perhaps even 9.4 stuff as well). Patch is attached. Regards, -- Michael
Attachment
Re: GIN code managing entry insertion not able to differentiate fresh and old indexes
From
Michael Paquier
Date:
On Thu, Nov 20, 2014 at 5:22 PM, Michael Paquier <michael.paquier@gmail.com> wrote: > Patch is attached. A cleaner fix may be btw to pass the build stats in ginPrepareEntryScan and set the flag directly there. -- Michael
Re: GIN code managing entry insertion not able to differentiate fresh and old indexes
From
Bruce Momjian
Date:
On Thu, Nov 20, 2014 at 05:22:02PM +0900, Michael Paquier wrote: > Hi all, > > While playing with the GIN code for an upcoming patch, I noticed that > when inserting a new entry in a new index, this code path is not able > to make the difference if the index is in a build state or not. > Basically, when entering in ginEntryInsert@gininsert.c GinBtree built > via ginPrepareEntryScan does not have its flag isBuild set up > properly. I think that it should be set as follows to let this code > path be aware that index is in build state: > btree.isBuild = (buildStats != NULL); > > Note that the entry insertion code does nothing with isBuild yet, so > it does not really impact back-branches. However, if in the future we > fix a bug in this area and need to make distinction between a fresh > index and an old one well there will be problems. For those reasons, > this correctness fix should be perhaps master-only for now (perhaps > even 9.4 stuff as well). Where did we leave this? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. +
Re: GIN code managing entry insertion not able to differentiate fresh and old indexes
From
Michael Paquier
Date:
On Sat, Mar 21, 2015 at 7:27 AM, Bruce Momjian wrote: > On Thu, Nov 20, 2014 at 05:22:02PM +0900, Michael Paquier wrote: >> While playing with the GIN code for an upcoming patch, I noticed that >> when inserting a new entry in a new index, this code path is not able >> to make the difference if the index is in a build state or not. >> Basically, when entering in ginEntryInsert@gininsert.c GinBtree built >> via ginPrepareEntryScan does not have its flag isBuild set up >> properly. I think that it should be set as follows to let this code >> path be aware that index is in build state: >> btree.isBuild = (buildStats != NULL); >> >> Note that the entry insertion code does nothing with isBuild yet, so >> it does not really impact back-branches. However, if in the future we >> fix a bug in this area and need to make distinction between a fresh >> index and an old one well there will be problems. For those reasons, >> this correctness fix should be perhaps master-only for now (perhaps >> even 9.4 stuff as well). > > Where did we leave this? I recall Heikki mentioning me that the code paths where ginPrepareEntryScan is called do not make use of isBuild, so it does not matter much now to not fix it... But *if* there is a new feature implemented in gin that makes use of the flag isBuild there will be problems, so I am of the opinion to push a fix for correctness. -- Michael