| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Amit Kapila <amit(dot)kapila16(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-07 20:03:08 |
| Message-ID: | CA+TgmoYYnN9jLaWwzFUiwB1-rC=2q6xwqayuVNTCP+Cyc1Ku3Q@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2017-06-07 20:36:56 | Re: Re: Alter subscription..SET - NOTICE message is coming for table which is already removed |
| Previous Message | Robert Haas | 2017-06-07 19:50:41 | Re: statement_timeout is not working as expected with postgres_fdw |