From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Amit Langote <amitlangote09(at)gmail(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, hawu(at)vmware(dot)com |
Subject: | Re: default partition and concurrent attach partition |
Date: | 2020-09-07 22:05:41 |
Message-ID: | 20200907220541.GA13103@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2020-Sep-04, Amit Langote wrote:
Hello
> FWIW, I still prefer "minimally valid ResultRelInfo" to "fake
> ResultRelInfo", because those aren't really fake, are they? They are
> as valid as any other ResultRelInfo as far I can see. I said
> "minimally valid" because a fully-valid partition ResultRelInfo is one
> made by ExecInitPartitionInfo(), which I avoided to use here thinking
> that would be overkill.
Well, they are fake in that the ri_RangeTableIndex they carry is bogus,
which means that ExecBuildSlotValueDescription will misbehave if the
partitioned default partition has a different column order than its
parent. That can be evidenced by changing the setup block in the
isolation test as in the attached; and you'll get an undesirable error
like this:
2020-09-07 19:00:49.513 -03 [12981] ERROR: attribute 2 of type record has wrong type
2020-09-07 19:00:49.513 -03 [12981] DETAIL: Table has type text, but query expects integer.
2020-09-07 19:00:49.513 -03 [12981] STATEMENT: insert into attach_tab values (110, 'eleven and five twenties');
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachment | Content-Type | Size |
---|---|---|
ff.spec | text/plain | 1.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2020-09-07 22:10:07 | Re: default partition and concurrent attach partition |
Previous Message | Thomas Munro | 2020-09-07 22:03:28 | Re: A micro-optimisation for walkdir() |