Fujita-san,
On 2019/04/24 18:55, Etsuro Fujita wrote:
> (2019/04/23 10:03), Amit Langote wrote:
>> Thanks for adding me as an author, but I think the latest
>> patch is mostly your work, so I'm happy to be listed as just a reviewer. :)
>
> You found this bug, analyzed it, and wrote the first vers
(2019/04/23 10:03), Amit Langote wrote:
So, it seems to OK to keep this commit this as one patch.
I read your commit message and it seems to sufficiently explain the issues
being fixed.
Cool!
Thanks for adding me as an author, but I think the latest
patch is mostly your work, so I'm happy
Fujita-san,
On 2019/04/22 20:00, Etsuro Fujita wrote:
> (2019/04/19 14:39), Etsuro Fujita wrote:
>> (2019/04/19 13:00), Amit Langote wrote:
>>> I agree that we can move to fix the other issue right away as the fix you
>>> outlined above seems reasonable, but I wonder if it wouldn't be better to
>>
(2019/04/19 14:39), Etsuro Fujita wrote:
(2019/04/19 13:00), Amit Langote wrote:
On 2019/04/18 22:10, Etsuro Fujita wrote:
On 2019/04/18 14:06, Amit Langote wrote:
On 2019/04/17 21:49, Etsuro Fujita wrote:
So what I'm thinking is to throw an error for cases like this.
(Though, I
think we shou
On 2019/04/19 14:39, Etsuro Fujita wrote:
> (2019/04/19 13:00), Amit Langote wrote:
>> On 2019/04/18 22:10, Etsuro Fujita wrote:
>>> * I kept all the changes in the previous patch, because otherwise
>>> postgres_fdw would fail to release resources for a foreign-insert
>>> operation created by postg
(2019/04/19 13:17), Amit Langote wrote:
OTOH, we don't mention at all in postgres-fdw.sgml
that postgres_fdw supports tuple routing. Maybe we should and list this
limitation or would it be too much burden to maintain?
I think it's better to add this limitation to postgres-fdw.sgml. Will
do.
(2019/04/19 13:00), Amit Langote wrote:
On 2019/04/18 22:10, Etsuro Fujita wrote:
On 2019/04/18 14:06, Amit Langote wrote:
On 2019/04/17 21:49, Etsuro Fujita wrote:
So what I'm thinking is to throw an error for cases like this.
(Though, I
think we should keep to allow rows to be moved from loc
On 2019/04/19 13:00, Amit Langote wrote:
> BTW, do you think we should update the docs regarding the newly
> established limitation of row movement involving foreign tables?
Ah, maybe not, because it's a postgres_fdw limitation, not of the core
tuple routing feature. OTOH, we don't mention at all
Fujita-san,
On 2019/04/18 22:10, Etsuro Fujita wrote:
>> On 2019/04/18 14:06, Amit Langote wrote:
>>> On 2019/04/17 21:49, Etsuro Fujita wrote:
So what I'm thinking is to throw an error for cases like this.
(Though, I
think we should keep to allow rows to be moved from local partit
(2019/04/18 22:10), Etsuro Fujita wrote:
Notes:
* I kept all the changes in the previous patch, because otherwise
postgres_fdw would fail to release resources for a foreign-insert
operation created by postgresBeginForeignInsert() for a tuple-routable
foreign table (ie, a foreign-table subplan re
Amit-san,
Thanks for the comments!
(2019/04/18 14:08), Amit Langote wrote:
On 2019/04/18 14:06, Amit Langote wrote:
On 2019/04/17 21:49, Etsuro Fujita wrote:
I think the reason for that is: the row routed to remp is incorrectly
fetched as a to-be-updated row when updating remp as a subplan
On 2019/04/18 14:06, Amit Langote wrote:
> Fujita-san,
>
> On 2019/04/17 21:49, Etsuro Fujita wrote:
>> (2019/04/11 20:31), Etsuro Fujita wrote:
>>> (2019/04/11 14:33), Amit Langote wrote:
BTW, have you noticed that the RETURNING clause returns the same row
twice?
>>>
>>> I noticed this,
Fujita-san,
On 2019/04/17 21:49, Etsuro Fujita wrote:
> (2019/04/11 20:31), Etsuro Fujita wrote:
>> (2019/04/11 14:33), Amit Langote wrote:
>>> BTW, have you noticed that the RETURNING clause returns the same row
>>> twice?
>>
>> I noticed this, but I didn't think it hard. :(
>>
>>> +update utrtes
(2019/04/11 20:31), Etsuro Fujita wrote:
(2019/04/11 14:33), Amit Langote wrote:
BTW, have you noticed that the RETURNING clause returns the same row
twice?
I noticed this, but I didn't think it hard. :(
+update utrtest set a = 3 from (values (2), (3)) s(x) where a = s.x
returning *;
+ a | b
(2019/04/11 14:33), Amit Langote wrote:
On 2019/04/10 17:38, Etsuro Fujita wrote:
(2019/03/06 18:33), Amit Langote wrote:
I noticed a bug with how UPDATE tuple routing initializes ResultRelInfos
to use for partition routing targets. Specifically, the bug occurs when
UPDATE targets include a fo
Fujita-san,
Thanks for the review.
On 2019/04/10 17:38, Etsuro Fujita wrote:
> (2019/03/06 18:33), Amit Langote wrote:
>> I noticed a bug with how UPDATE tuple routing initializes ResultRelInfos
>> to use for partition routing targets. Specifically, the bug occurs when
>> UPDATE targets include
(2019/03/06 18:33), Amit Langote wrote:
I noticed a bug with how UPDATE tuple routing initializes ResultRelInfos
to use for partition routing targets. Specifically, the bug occurs when
UPDATE targets include a foreign partition that is locally modified (as
opposed to being modified directly on t
Hi Amit,
(2019/03/06 18:33), Amit Langote wrote:
I noticed a bug with how UPDATE tuple routing initializes ResultRelInfos
to use for partition routing targets. Specifically, the bug occurs when
UPDATE targets include a foreign partition that is locally modified (as
opposed to being modified dir
18 matches
Mail list logo
