pgsql: Fix partitioned index creation with foreign partitions

Started by Alvaro Herreraabout 7 years ago4 messagescomitters
Jump to latest
#1Alvaro Herrera
alvherre@2ndquadrant.com

Fix partitioned index creation with foreign partitions

When a partitioned tables contains foreign tables as partitions, it is
not possible to implement unique or primary key indexes -- but when
regular indexes are created, there is no reason to do anything other
than ignoring such partitions. We were raising errors upon encountering
the foreign partitions, which is unfriendly and doesn't protect against
any actual problems.

Relax this restriction so that index creation is allowed on partitioned
tables containing foreign partitions, becoming a no-op on them. (We may
later want to redefine this so that the FDW is told to create the
indexes on the foreign side.) This applies to CREATE INDEX, as well as
ALTER TABLE / ATTACH PARTITION and CREATE TABLE / PARTITION OF.

Backpatch to 11, where indexes on partitioned tables were introduced.

Discussion: /messages/by-id/15724-d5a58fa9472eef4f@postgresql.org
Author: Álvaro Herrera
Reviewed-by: Amit Langote

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/55ed3defc966cf718fe1e8c0efe964580bb23351

Modified Files
--------------
doc/src/sgml/ref/alter_table.sgml | 2 +-
doc/src/sgml/ref/create_foreign_table.sgml | 4 +--
src/backend/commands/indexcmds.c | 20 +++++++++++
src/backend/commands/tablecmds.c | 45 ++++++++++++++++++++++++
src/backend/tcop/utility.c | 12 +++++--
src/test/regress/expected/foreign_data.out | 56 ++++++++++++++++++++++++++++--
src/test/regress/sql/foreign_data.sql | 42 +++++++++++++++++++++-
7 files changed, 172 insertions(+), 9 deletions(-)

#2Alvaro Herrera
alvherre@2ndquadrant.com
In reply to: Alvaro Herrera (#1)
Re: pgsql: Fix partitioned index creation with foreign partitions

On 2019-Jun-26, Alvaro Herrera wrote:

Fix partitioned index creation with foreign partitions

Hmm, so this causes prion to fail, because -DFORCE_RELCACHE_RELEASE: it
reports the immediate parent of the would-be-partition rather than the
topmost ancestor. I'm not sure I understand why, since relcache release
shouldn't affect recursion order (maybe that's another bug). I'll
investigate more tomorrow.

--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

#3Amit Langote
Langote_Amit_f8@lab.ntt.co.jp
In reply to: Alvaro Herrera (#2)
Re: pgsql: Fix partitioned index creation with foreign partitions

On Thu, Jun 27, 2019 at 8:04 AM Alvaro Herrera <alvherre@2ndquadrant.com> wrote:

On 2019-Jun-26, Alvaro Herrera wrote:

Fix partitioned index creation with foreign partitions

Hmm, so this causes prion to fail, because -DFORCE_RELCACHE_RELEASE: it
reports the immediate parent of the would-be-partition rather than the
topmost ancestor. I'm not sure I understand why, since relcache release
shouldn't affect recursion order (maybe that's another bug). I'll
investigate more tomorrow.

I see this diff:

 ALTER TABLE lt1 ADD PRIMARY KEY (a);
-ERROR:  cannot create unique index on partitioned table "lt1_part1"
-DETAIL:  Table "lt1_part1" contains partitions that are foreign tables.
+ERROR:  cannot create unique index on partitioned table "ft_part_1_1"
+DETAIL:  Table "ft_part_1_1" contains partitions that are foreign tables.

The table name reported here is that of the foreign table leaf
partition, not of the immediate parent. Also, what's expected is not
the topmost ancestor, but the immediate parent, which seems OK,
because that's the best that the code in question can manage.

Anyway, the problem seems to use-after-close of a Relation pointer,
which the attached patch fixes.

Thanks,
Amit

Attachments:

DefineIndex-fix-use-after-relation-close.patchapplication/octet-stream; name=DefineIndex-fix-use-after-relation-close.patchDownload+2-4
#4Alvaro Herrera
alvherre@2ndquadrant.com
In reply to: Amit Langote (#3)
Re: pgsql: Fix partitioned index creation with foreign partitions

On 2019-Jun-27, Amit Langote wrote:

Anyway, the problem seems to use-after-close of a Relation pointer,
which the attached patch fixes.

Indeed, thanks for tracking it down. Pushed. I couldn't resist the
temptation remove a no-longer-necessary tupdesc copy while at it.

--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services