From: | Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> |
---|---|
To: | Amit Langote <amitlangote09(at)gmail(dot)com> |
Cc: | amul sul <sulamul(at)gmail(dot)com>, Rajkumar Raghuwanshi <rajkumar(dot)raghuwanshi(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Getting ERROR with FOR UPDATE/SHARE for partitioned table. |
Date: | 2020-05-28 14:07:55 |
Message-ID: | CAExHW5uqL-em7EeBk6=n7WO=KYzPZz=K4-J2xO41WNx836zKVg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, May 27, 2020 at 6:51 PM Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
>
> So in Rajkumar's example, the cursor is declared as:
>
> CURSOR IS SELECT * FROM tbl WHERE c1< 5 FOR UPDATE;
>
> and the WHERE CURRENT OF query is this:
>
> UPDATE tbl SET c2='aa' WHERE CURRENT OF cur;
Thanks for the clarification. So it looks like we expand UPDATE on
partitioned table to UPDATE on each partition (inheritance_planner for
DML) and then execute each of those. If CURRENT OF were to save the
table oid or something we could run the UPDATE only on that partition.
I am possibly shooting in dark, but this puzzles me. And it looks like
we can cause wrong rows to be updated in non-partition inheritance
where the ctids match?
--
Best Wishes,
Ashutosh Bapat
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2020-05-28 14:19:11 | Re: Explain Analyze (Rollback off) Suggestion |
Previous Message | Stephen Frost | 2020-05-28 14:01:23 | Re: password_encryption default |