Re: UPDATE of partition key

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Amit Khandekar <amitdkhan(dot)pg(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: UPDATE of partition key
Date: 2017-06-08 11:01:46
Message-ID: CAA4eK1Lba7xtbEmXiW_4K4cnMLszc0aUdfekH603ocCjzd5tnA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jun 8, 2017 at 1:33 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Wed, Jun 7, 2017 at 5:46 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>> As far as I understand, it is to ensure that for deleted rows, nothing
>> more needs to be done. For example, see the below check in
>> ExecUpdate/ExecDelete.
>> if (!ItemPointerEquals(tupleid, &hufd.ctid))
>> {
>> ..
>> }
>> ..
>>
>> Also a similar check in ExecLockRows. Now for deleted rows, if the
>> t_ctid wouldn't point to itself, then in the mentioned functions, we
>> were not in a position to conclude that the row is deleted.
>
> Right, so we would have to find all such checks and change them to use
> some other method to conclude that the row is deleted. What method
> would we use?
>

I think before doing above check we can simply check if ctid.ip_blkid
contains InvalidBlockNumber, then return an error.

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message K S, Sandhya (Nokia - IN/Bangalore) 2017-06-08 12:25:14 Re: [BUGS] Crash observed during the start of the Postgres process
Previous Message Jeevan Ladhe 2017-06-08 10:59:49 Re: Adding support for Default partition in partitioning