Re: a misbehavior of partition row movement (?)

From: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
To: Amit Langote <amitlangote09(at)gmail(dot)com>
Cc: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: a misbehavior of partition row movement (?)
Date: 2020-10-03 11:15:09
Message-ID: 20201003111509.hgxgu46uj7hijmvd@development
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Oct 03, 2020 at 11:42:21AM +0900, Amit Langote wrote:
>On Fri, Oct 2, 2020 at 11:32 PM David G. Johnston
><david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
>> On Friday, October 2, 2020, Amit Langote <amitlangote09(at)gmail(dot)com>
>> wrote:
>>>
>>>
>>> Reporter on that thread says that the last update should have failed
>>> and I don't quite see a workable alternative to that.
>>
>>
>> To be clear the OP would rather have it just work, the same as the
>> non-row-movement version. Maybe insert the new row first, execute
>> the on update trigger chained from the old row, then delete the old
>> row?
>
>I was thinking yesterday about making it just work, but considering the
>changes that would need to be made to how the underlying triggers fire,
>it does not seem we would be able to back-port the solution.
>

I think we need to differentiate between master and backbranches. IMO we
should try to make it "just work" in master, and the amount of code
should not be an issue there I think (no opinion on whether insert and
update trigger is the way to go). For backbranches we may need to do
something less intrusive, of course.

regards

--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2020-10-03 11:26:19 Re: a misbehavior of partition row movement (?)
Previous Message Amit Kapila 2020-10-03 11:03:11 Re: VACUUM PARALLEL option vs. max_parallel_maintenance_workers