(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
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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
(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,
Etsu
(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. S
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.
>>
>> Committed.
Thank you.
> There's stil
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 this thread - has that been
resolv
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
On 2018/04/27 10:01, Kyotaro HORIGUCHI wrote:
> At Thu, 26 Apr 2018 21:16:38 +0900, Etsuro Fujita wrote:
>> (2018/04/26 20:06), Kyotaro HORIGUCHI wrote:
>>> Agreed on all points above.
>>
>> Thanks for reviewing!
>
> I'm happy if it helps you.
Thank you both for reviewing.
Regards,
Amit
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 resultRelInfo.
>
> Maybe I don't understa
(2018/04/26 20:06), Kyotaro HORIGUCHI wrote:
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:
+resultRelat
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 == plan->nominalRelation)
> > + re
(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.
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 the patch to fix the bug of fore
(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 comme
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 n
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 = list_nth(estate->
(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);
+ rte->r
(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 the bug of 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;
+rte->rel
(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 r
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
>
> Thoughts?
Are you splitting t
(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?
Thanks for the ping. I just had a look over the proposed patch
Horiguchi-san,
Thanks for taking a look at it.
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_RELAT
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 wrote:
> > I have done some refactori
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 still
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:
> >> On Mon, Apr 23, 2018 at 11:25 AM, Alvaro Herrera
> >> wrote:
> >>> Robert, I think this is your turf, per
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?
>>
>> Thanks for the ping. I just had a look over the
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
> > wrote:
> >> Robert, I think this is your turf, per 3d956d9562aa. Are you looking
> >> into it?
> >
> > Thanks for th
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 the proposed patch and I
> guess I don't like it v
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 range
table in place and the
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
(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 planner
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
(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, ExecInitParititionInfo calls
ExecInitRo
(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 resultRelIn
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
> >> ExecInitRoutingInfo so currently CheckValid
On 2018/04/18 21:55, Etsuro Fujita wrote:
> (2018/04/18 14:44), Amit Langote wrote:
>> Oh, I didn't really consider this part carefully. That the resultRelInfo
>> received by BeginForeignInsert (when called by ExecInitRoutingInfo) could
>> be a reused UPDATE result relation. It might be possible
(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 th
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 R
(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 Ch
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 partiti
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 that
> > the patch for tuple routing for foreign partitions doesn't work well
> > wit
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:
>>
>> postgre
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 chec
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 br_insert_trigfunc(
45 matches
Mail list logo
