Re: Oddity in tuple routing for foreign partitions

(2018/05/03 9:29), Robert Haas wrote: On Wed, May 2, 2018 at 7:06 AM, Etsuro Fujita wrote: Here is a small patch to remove a no-longer-needed cast in postgresBeginForeignInsert(). Committed. Thanks! Best regards, Etsuro Fujita

Re: Oddity in tuple routing for foreign partitions

(2018/05/02 15:45), Etsuro Fujita wrote: (2018/05/02 10:10), Amit Langote wrote: On 2018/05/02 6:09, Andres Freund wrote: On 2018-05-01 13:41:32 -0400, Robert Haas wrote: Committed. Here is a small patch to remove a no-longer-needed cast in postgresBeginForeignInsert(). Best regards,

Re: Oddity in tuple routing for foreign partitions

(2018/05/02 10:10), Amit Langote wrote: On 2018/05/02 6:09, Andres Freund wrote: On 2018-05-01 13:41:32 -0400, Robert Haas wrote: Committed. Thank you. Thanks for committing, Robert! There's still an open items entry for this thread - has that been resolved by this commit Afaik, yes.

Re: Oddity in tuple routing for foreign partitions

On 2018/05/02 6:09, Andres Freund wrote: > On 2018-05-01 13:41:32 -0400, Robert Haas wrote: >> On Thu, Apr 26, 2018 at 9:23 PM, Amit Langote >> wrote: > Thanks for reviewing! I'm happy if it helps you. >>> >>> Thank you both for reviewing. >> >>

Re: Oddity in tuple routing for foreign partitions

On 2018-05-01 13:41:32 -0400, Robert Haas wrote: > On Thu, Apr 26, 2018 at 9:23 PM, Amit Langote > wrote: > >>> Thanks for reviewing! > >> > >> I'm happy if it helps you. > > > > Thank you both for reviewing. > > Committed. There's still an open items entry for

Re: Oddity in tuple routing for foreign partitions

On Thu, Apr 26, 2018 at 9:23 PM, Amit Langote wrote: >>> Thanks for reviewing! >> >> I'm happy if it helps you. > > Thank you both for reviewing. Committed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: Oddity in tuple routing for foreign partitions

At Thu, 26 Apr 2018 21:16:38 +0900, Etsuro Fujita wrote in <5ae1c326.6040...@lab.ntt.co.jp> > (2018/04/26 20:06), Kyotaro HORIGUCHI wrote: > > Please rewrite it to use not array reference, but pointer > > reference if one mtstate logically holds just one

Re: Oddity in tuple routing for foreign partitions

It seems almost fine for me, but just one point.. At Thu, 26 Apr 2018 17:36:44 +0900, Etsuro Fujita wrote in <5ae18f9c.6080...@lab.ntt.co.jp> > (2018/04/26 15:35), Amit Langote wrote: > > On 2018/04/26 12:43, Etsuro Fujita wrote: > > +resultRelation ==

Re: Oddity in tuple routing for foreign partitions

(2018/04/26 15:35), Amit Langote wrote: On 2018/04/26 12:43, Etsuro Fujita wrote: (2018/04/25 17:29), Amit Langote wrote: Hmm, I missed that we do need information from a proper RTE as well. So, I suppose we should be doing this instead of creating the RTE for foreign partition from scratch.

Re: Oddity in tuple routing for foreign partitions

On 2018/04/26 2:59, Robert Haas wrote: > On Tue, Apr 24, 2018 at 10:19 PM, Amit Langote > wrote: >> I tried to do that. So, attached are two patches. >> >> 1. Fix for ExecInitPartitionInfo to use the right RT index to pass to >>InitResultRelInfo >> >> 2. v5 of

Re: Oddity in tuple routing for foreign partitions

(2018/04/26 15:39), Amit Langote wrote: On 2018/04/26 15:27, Etsuro Fujita wrote: Here is a new version I'd like to propose for fixing this issue without the former patch. Sorry, didn't notice this before sending my patch, which I also marked v7. It's a bit different than yours and has

Re: Oddity in tuple routing for foreign partitions

On 2018/04/26 15:27, Etsuro Fujita wrote: > (2018/04/26 12:43), Etsuro Fujita wrote: >> (2018/04/25 17:29), Amit Langote wrote: >>> On 2018/04/25 16:42, Kyotaro HORIGUCHI wrote: At Wed, 25 Apr 2018 11:19:23 +0900, Amit Langote wrote: > After the refactoring, it appears to me that we only

Re: Oddity in tuple routing for foreign partitions

On 2018/04/26 12:43, Etsuro Fujita wrote: > (2018/04/25 17:29), Amit Langote wrote: >> Hmm, I missed that we do need information from a proper RTE as well.  So, >> I suppose we should be doing this instead of creating the RTE for foreign >> partition from scratch. >> >> +    rte =

Re: Oddity in tuple routing for foreign partitions

(2018/04/26 12:43), Etsuro Fujita wrote: (2018/04/25 17:29), Amit Langote wrote: On 2018/04/25 16:42, Kyotaro HORIGUCHI wrote: At Wed, 25 Apr 2018 11:19:23 +0900, Amit Langote wrote: After the refactoring, it appears to me that we only need this much: + rte = makeNode(RangeTblEntry); +

Re: Oddity in tuple routing for foreign partitions

(2018/04/26 2:59), Robert Haas wrote: On Tue, Apr 24, 2018 at 10:19 PM, Amit Langote wrote: I tried to do that. So, attached are two patches. 1. Fix for ExecInitPartitionInfo to use the right RT index to pass to InitResultRelInfo 2. v5 of the patch to fix

Re: Oddity in tuple routing for foreign partitions

(2018/04/25 17:29), Amit Langote wrote: On 2018/04/25 16:42, Kyotaro HORIGUCHI wrote: At Wed, 25 Apr 2018 11:19:23 +0900, Amit Langote wrote: After the refactoring, it appears to me that we only need this much: +rte = makeNode(RangeTblEntry); +rte->rtekind = RTE_RELATION; +

Re: Oddity in tuple routing for foreign partitions

(2018/04/25 17:51), Etsuro Fujita wrote: (2018/04/25 4:49), Robert Haas wrote: I didn't really get beyond the refactoring stage with this today. This version still seems to work, but I don't really understand the logic in postgresBeginForeignInsert which decides whether to use the RTE from the

Re: Oddity in tuple routing for foreign partitions

On Tue, Apr 24, 2018 at 10:19 PM, Amit Langote wrote: > I tried to do that. So, attached are two patches. > > 1. Fix for ExecInitPartitionInfo to use the right RT index to pass to >InitResultRelInfo > > 2. v5 of the patch to fix the bug of foreign partitions >

Re: Oddity in tuple routing for foreign partitions

At Wed, 25 Apr 2018 11:19:23 +0900, Amit Langote wrote in <573e60cc-beeb-b534-d89a-7622fae35...@lab.ntt.co.jp> > Oops, really meant to send the "+1 to the root -> rte refactoring" comment > and the rest in the same email. > > On 2018/04/25 4:49, Robert Haas

Re: Oddity in tuple routing for foreign partitions

Oops, really meant to send the "+1 to the root -> rte refactoring" comment and the rest in the same email. On 2018/04/25 4:49, Robert Haas wrote: > I have done some refactoring to avoid that. See attached. > > I didn't really get beyond the refactoring stage with this today. > This version

Re: Oddity in tuple routing for foreign partitions

I forgot to mention that. At Wed, 25 Apr 2018 10:17:02 +0900, Amit Langote wrote in > On 2018/04/25 4:49, Robert Haas wrote: > > On Tue, Apr 24, 2018 at 12:21 PM, Robert Haas wrote: > >>

Re: Oddity in tuple routing for foreign partitions

On 2018/04/25 4:49, Robert Haas wrote: > On Tue, Apr 24, 2018 at 12:21 PM, Robert Haas wrote: >> On Mon, Apr 23, 2018 at 11:25 AM, Alvaro Herrera >> wrote: >>> Robert, I think this is your turf, per 3d956d9562aa. Are you looking >>> into it? >> >>

Re: Oddity in tuple routing for foreign partitions

Hello. At Tue, 24 Apr 2018 15:49:20 -0400, Robert Haas wrote in > On Tue, Apr 24, 2018 at 12:21 PM, Robert Haas wrote: > > On Mon, Apr 23, 2018 at 11:25 AM, Alvaro Herrera > >

Re: Oddity in tuple routing for foreign partitions

On Tue, Apr 24, 2018 at 12:21 PM, Robert Haas wrote: > On Mon, Apr 23, 2018 at 11:25 AM, Alvaro Herrera > wrote: >> Robert, I think this is your turf, per 3d956d9562aa. Are you looking >> into it? > > Thanks for the ping. I just had a look over

Re: Oddity in tuple routing for foreign partitions

On Mon, Apr 23, 2018 at 11:25 AM, Alvaro Herrera wrote: > Robert, I think this is your turf, per 3d956d9562aa. Are you looking > into it? Thanks for the ping. I just had a look over the proposed patch and I guess I don't like it very much. Temporarily modifying the

Re: Oddity in tuple routing for foreign partitions

Robert, I think this is your turf, per 3d956d9562aa. Are you looking into it? Thanks, -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: Oddity in tuple routing for foreign partitions

(2018/04/20 9:48), Amit Langote wrote: On 2018/04/19 21:42, Etsuro Fujita wrote: (2018/04/19 16:43), Amit Langote wrote: Would it be a good idea to explain *why* we need to replace the RTE in the first place? Afaics, it's for deparseColumnRef() to find the correct relation when it uses

Re: Oddity in tuple routing for foreign partitions

Fujita-san, Thanks for the updated patch. On 2018/04/19 21:42, Etsuro Fujita wrote: > (2018/04/19 16:43), Amit Langote wrote: >> Would it be a good idea to explain *why* we need to replace the RTE in the >> first place?  Afaics, it's for deparseColumnRef() to find the correct >> relation when it

Re: Oddity in tuple routing for foreign partitions

(2018/04/19 19:03), Kyotaro HORIGUCHI wrote: At Tue, 17 Apr 2018 16:41:31 +0900, Etsuro Fujita wrote in<5ad5a52b.7050...@lab.ntt.co.jp> (2018/04/17 16:10), Amit Langote wrote: On 2018/04/17 11:13, Kyotaro HORIGUCHI wrote: If I'm reading this correctly,

Re: Oddity in tuple routing for foreign partitions

(2018/04/19 16:43), Amit Langote wrote: On 2018/04/18 21:55, Etsuro Fujita wrote: (2018/04/18 14:44), Amit Langote wrote: That the resultRelInfo received by BeginForeignInsert (when called by ExecInitRoutingInfo) could be a reused UPDATE result relation. 2. This is UPDATE and the

Re: Oddity in tuple routing for foreign partitions

At Tue, 17 Apr 2018 16:41:31 +0900, Etsuro Fujita wrote in <5ad5a52b.7050...@lab.ntt.co.jp> > (2018/04/17 16:10), Amit Langote wrote: > > On 2018/04/17 11:13, Kyotaro HORIGUCHI wrote: > >> If I'm reading this correctly, ExecInitParititionInfo calls > >>

Re: Oddity in tuple routing for foreign partitions

(2018/04/18 14:44), Amit Langote wrote: On 2018/04/17 16:41, Etsuro Fujita wrote: In the INSERT/COPY-tuple-routing case, as explained by Amit, the RTE at that position in the EState's range table is the one for the partitioned table of a given partition, so the statement would be true. BUT in

Re: Oddity in tuple routing for foreign partitions

On 2018/04/17 16:41, Etsuro Fujita wrote: > In the INSERT/COPY-tuple-routing case, as explained by Amit, the > RTE at that position in the EState's range table is the one for the > partitioned table of a given partition, so the statement would be true.  > BUT in the UPDATE-tuple-routing case, the

Re: Oddity in tuple routing for foreign partitions

(2018/04/17 16:10), Amit Langote wrote: On 2018/04/17 11:13, Kyotaro HORIGUCHI wrote: If I'm reading this correctly, ExecInitParititionInfo calls ExecInitRoutingInfo so currently CheckValidityResultRel is called for the child when partrel is created in ExecPrepareTupleRouting. But the move of

Re: Oddity in tuple routing for foreign partitions

On 2018/04/17 11:13, Kyotaro HORIGUCHI wrote: >>> Also, I removed the CheckValidResultRel check from ExecInitRoutingInfo >>> and added that to ExecInitPartitionInfo right after the> InitResultRelInfo >>> call, >>> because it would be better to abort the >>> operation as soon as we find the

Re: Oddity in tuple routing for foreign partitions

Hello. At Tue, 17 Apr 2018 10:10:38 +0900, Amit Langote wrote in > Fujita-san, > > On 2018/04/16 20:25, Etsuro Fujita wrote: > > Hi, > > > > While updating the fix-postgres_fdw-WCO-handling patch, I noticed

Re: Oddity in tuple routing for foreign partitions

Hi Amit, (2018/04/17 10:10), Amit Langote wrote: > On 2018/04/16 20:25, Etsuro Fujita wrote: >> While updating the fix-postgres_fdw-WCO-handling patch, I noticed that >> the patch for tuple routing for foreign partitions doesn't work well >> with remote triggers. Here is an example: >> >>

Re: Oddity in tuple routing for foreign partitions

Fujita-san, On 2018/04/16 20:25, Etsuro Fujita wrote: > Hi, > > While updating the fix-postgres_fdw-WCO-handling patch, I noticed that > the patch for tuple routing for foreign partitions doesn't work well > with remote triggers. Here is an example: > > postgres=# create table loct1 (a int

Oddity in tuple routing for foreign partitions

Hi, While updating the fix-postgres_fdw-WCO-handling patch, I noticed that the patch for tuple routing for foreign partitions doesn't work well with remote triggers. Here is an example: postgres=# create table loct1 (a int check (a in (1)), b text); postgres=# create function