Thread: pgsql: Get rid of pg_class.reltoastidxid.
Get rid of pg_class.reltoastidxid. Treat TOAST index just the same as normal one and get the OID of TOAST index from pg_index but not pg_class.reltoastidxid. This change allows us to handle multiple TOAST indexes, and which is required infrastructure for upcoming REINDEX CONCURRENTLY feature. Patch by Michael Paquier, reviewed by Andres Freund and me. Branch ------ master Details ------- http://git.postgresql.org/pg/commitdiff/2ef085d0e6960f5087c97266a7211d37ddaa9f68 Modified Files -------------- contrib/pg_upgrade/info.c | 15 ++- doc/src/sgml/catalogs.sgml | 9 -- doc/src/sgml/diskusage.sgml | 26 ++-- doc/src/sgml/monitoring.sgml | 4 +- src/backend/access/heap/tuptoaster.c | 225 +++++++++++++++++++++++++++----- src/backend/catalog/heap.c | 1 - src/backend/catalog/index.c | 23 +--- src/backend/catalog/system_views.sql | 10 +- src/backend/commands/cluster.c | 34 +++-- src/backend/commands/tablecmds.c | 20 ++- src/backend/rewrite/rewriteDefine.c | 5 +- src/backend/utils/adt/dbsize.c | 24 +++- src/bin/pg_dump/pg_dump.c | 14 +- src/include/access/tuptoaster.h | 9 ++ src/include/catalog/catversion.h | 2 +- src/include/catalog/pg_class.h | 44 +++---- src/test/regress/expected/oidjoins.out | 8 -- src/test/regress/expected/rules.out | 16 +-- src/test/regress/sql/oidjoins.sql | 4 - src/test/regress/sql/rules.sql | 2 +- src/tools/findoidjoins/README | 1 - 21 files changed, 333 insertions(+), 163 deletions(-)
Hi Fujii, Michael, Coverity indicated that there's a problem with this - a quick look confirms that: foreach(lc, indexlist) (*toastidxs)[i++] = index_open(lfirst_oid(lc), lock); /* Fetch the first valid index in list */ for (i = 0; i < *num_indexes; i++) { Relation toastidx = *toastidxs[i]; if (toastidx->rd_index->indisvalid) { res = i; found = true; break; } } Note how the second access to toastidxs is missing parentheses. It should be (*toastidxs)[i]. I think this happens to mostly work because usually the older index will still be valid when we open the toast indexes when there are multiple ones and RelationGetIndexList() returns indexes in toast order. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
On Wed, Jan 15, 2014 at 9:29 PM, Andres Freund <andres@2ndquadrant.com> wrote: > Hi Fujii, Michael, > > Coverity indicated that there's a problem with this - a quick look > confirms that: > > foreach(lc, indexlist) > (*toastidxs)[i++] = index_open(lfirst_oid(lc), lock); > > /* Fetch the first valid index in list */ > for (i = 0; i < *num_indexes; i++) > { > Relation toastidx = *toastidxs[i]; > if (toastidx->rd_index->indisvalid) > { > res = i; > found = true; > break; > } > } > > Note how the second access to toastidxs is missing parentheses. It > should be (*toastidxs)[i]. > > I think this happens to mostly work because usually the older index will > still be valid when we open the toast indexes when there are multiple > ones and RelationGetIndexList() returns indexes in toast order. Oops, good catch. If someone could show up and commit the attached to master and REL9_3_STABLE... Regards, -- Michael
On Wed, Jan 15, 2014 at 7:54 AM, Michael Paquier <michael.paquier@gmail.com> wrote: > Oops, good catch. If someone could show up and commit the attached to > master and REL9_3_STABLE... Hmm, I don't see an attachment. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Wed, Jan 15, 2014 at 10:02 PM, Robert Haas <robertmhaas@gmail.com> wrote: > On Wed, Jan 15, 2014 at 7:54 AM, Michael Paquier > <michael.paquier@gmail.com> wrote: >> Oops, good catch. If someone could show up and commit the attached to >> master and REL9_3_STABLE... > > Hmm, I don't see an attachment. Re-oops. Sorry I forgot it. -- Michael
Attachment
On Wed, Jan 15, 2014 at 8:14 AM, Michael Paquier <michael.paquier@gmail.com> wrote: > On Wed, Jan 15, 2014 at 10:02 PM, Robert Haas <robertmhaas@gmail.com> wrote: >> On Wed, Jan 15, 2014 at 7:54 AM, Michael Paquier >> <michael.paquier@gmail.com> wrote: >>> Oops, good catch. If someone could show up and commit the attached to >>> master and REL9_3_STABLE... >> >> Hmm, I don't see an attachment. > Re-oops. Sorry I forgot it. Committed to master, but I don't think this code exists in REL9_3_STABLE. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company