GIN code managing entry insertion not able to differentiate fresh and old indexes
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
Attachments:
20141120_gin_entry_build_fix.patchapplication/x-patch; name=20141120_gin_entry_build_fix.patchDownload
diff --git a/src/backend/access/gin/gininsert.c b/src/backend/access/gin/gininsert.c
index 370884e..229167b 100644
--- a/src/backend/access/gin/gininsert.c
+++ b/src/backend/access/gin/gininsert.c
@@ -191,6 +191,7 @@ ginEntryInsert(GinState *ginstate,
buildStats->nEntries++;
ginPrepareEntryScan(&btree, attnum, key, category, ginstate);
+ btree.isBuild = (buildStats != NULL);
stack = ginFindLeafPage(&btree, false);
page = BufferGetPage(stack->buffer);
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers