Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On Sun, Apr 8, 2018 at 2:04 AM, Andres Freund wrote: > On 2018-04-07 20:13:36 +0530, amul sul wrote: >> Attached is the patch does the renaming of this tests -- need to apply >> to the top of v10 patch[1]. > > These indeed are a bit too long, so I went with the numbers.

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On 2018-04-07 20:13:36 +0530, amul sul wrote: > Attached is the patch does the renaming of this tests -- need to apply > to the top of v10 patch[1]. These indeed are a bit too long, so I went with the numbers. I've pushed the patch now. Two changes: - I've added one more error patch to

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

amul sul wrote: > On Sat, Apr 7, 2018 at 9:08 AM, Andres Freund wrote: > >> +test: partition-key-update-1 > >> +test: partition-key-update-2 > >> +test: partition-key-update-3 > > > > Can you give these more descriptive names please (or further combine them)? > > As I

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On Sat, Apr 7, 2018 at 9:08 AM, Andres Freund wrote: > Hi Tom, All, > > On 2018-04-06 14:19:02 +0530, amul sul wrote: >> Thanks for the reminder -- fixed in the attached version. > > Tom, this seems to be the best approach for fixing the visibility issues > around this. I've

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

Hi Tom, All, On 2018-04-06 14:19:02 +0530, amul sul wrote: > Thanks for the reminder -- fixed in the attached version. Tom, this seems to be the best approach for fixing the visibility issues around this. I've spent a good chunk of time looking at corruption issues like the ones you feared (see

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On Fri, Apr 6, 2018 at 1:19 PM, Amit Kapila wrote: > On Fri, Apr 6, 2018 at 12:50 PM, amul sul wrote: >> >> Updated patch attached. >> > > + if (ItemPointerIndicatesMovedPartitions()) > + ereport(ERROR, > +

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On Fri, Apr 6, 2018 at 12:50 PM, amul sul wrote: > > Updated patch attached. > + if (ItemPointerIndicatesMovedPartitions()) + ereport(ERROR, + (errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE), + errmsg("tuple to be locked was already moved to another partition due to

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On Thu, Apr 5, 2018 at 7:14 AM, Andres Freund wrote: > Hi, > > On 2018-04-02 11:26:38 -0400, Robert Haas wrote: >> On Wed, Mar 28, 2018 at 2:12 PM, Andres Freund wrote: [] > I've attached a noticeably editorialized patch: > > - I'm uncomfortable with

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On Fri, Apr 6, 2018 at 12:07 PM, amul sul wrote: > On Thu, Apr 5, 2018 at 10:17 AM, Amit Kapila wrote: >> On Thu, Apr 5, 2018 at 7:14 AM, Andres Freund wrote: >>> > [...] >>> >>> Questions: >>> >>> - I'm not perfectly happy with

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On Thu, Apr 5, 2018 at 10:17 AM, Amit Kapila wrote: > On Thu, Apr 5, 2018 at 7:14 AM, Andres Freund wrote: >> [...] >> >> Questions: >> >> - I'm not perfectly happy with >> "tuple to be locked was already moved to another partition due to >>

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On Fri, Apr 6, 2018 at 1:13 AM, Andres Freund wrote: > On 2018-04-05 10:17:59 +0530, Amit Kapila wrote: >> On Thu, Apr 5, 2018 at 7:14 AM, Andres Freund wrote: >> Why? tid is both an input and output parameter. The input tid is >> valid and is verified

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On 2018-04-04 22:10:06 -0700, David G. Johnston wrote: > On Wednesday, April 4, 2018, Amit Kapila wrote: > > > On Thu, Apr 5, 2018 at 7:14 AM, Andres Freund wrote: > > > > > > > > Questions: > > > > > > - I'm not perfectly happy with > > > "tuple

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On Thu, Apr 5, 2018 at 7:14 AM, Andres Freund wrote: > > > I've attached a noticeably editorialized patch: > > + /* +* As long as we don't support an UPDATE of INSERT ON CONFLICT for +* a partitioned table we shouldn't reach to a case where

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On Thu, Apr 5, 2018 at 10:40 AM, David G. Johnston wrote: > On Wednesday, April 4, 2018, Amit Kapila wrote: >> >> On Thu, Apr 5, 2018 at 7:14 AM, Andres Freund wrote: >> > >> >> > Questions: >> > >> > - I'm not perfectly

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On Wednesday, April 4, 2018, Amit Kapila wrote: > On Thu, Apr 5, 2018 at 7:14 AM, Andres Freund wrote: > > > > > Questions: > > > > - I'm not perfectly happy with > > "tuple to be locked was already moved to another partition due to > concurrent

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On Thu, Apr 5, 2018 at 7:14 AM, Andres Freund wrote: > > I've attached a noticeably editorialized patch: > > - I'm uncomfortable with the "moved" information not being crash-safe / > replicated. Thus I added a new flag to preserve it, and removed the > masking of the moved

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

Hi, On 2018-04-02 11:26:38 -0400, Robert Haas wrote: > On Wed, Mar 28, 2018 at 2:12 PM, Andres Freund wrote: > > How will it break it? They'll see an invalid ctid and conclude that the > > tuple is dead? Without any changes that's already something that can > > happen if a

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On Wed, Apr 4, 2018 at 4:31 AM, Andres Freund wrote: > On 2018-03-06 19:57:03 +0530, Amit Kapila wrote: >> On Tue, Mar 6, 2018 at 4:53 AM, Andres Freund wrote: >> > Hi, >> > >> >> diff --git a/src/backend/executor/nodeLockRows.c >> >>

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On 2018-03-06 19:57:03 +0530, Amit Kapila wrote: > On Tue, Mar 6, 2018 at 4:53 AM, Andres Freund wrote: > > Hi, > > > >> diff --git a/src/backend/executor/nodeLockRows.c > >> b/src/backend/executor/nodeLockRows.c > >> index 7961b4be6a..b07b7092de 100644 > >> ---

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On Wed, Mar 28, 2018 at 2:12 PM, Andres Freund wrote: > How will it break it? They'll see an invalid ctid and conclude that the > tuple is dead? Without any changes that's already something that can > happen if a later tuple in the chain has been pruned away. Sure, that >

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

Hi, On 2018-03-28 13:52:24 -0400, Tom Lane wrote: > Andres Freund writes: > > Given, as explained nearby, we already do store transient data in the > > ctid for speculative insertions (i.e. ON CONFLICT), and it hasn't caused > > even a whiff of trouble, I'm currently not

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

Andres Freund writes: > On 2018-03-08 13:46:53 -0500, Tom Lane wrote: >> ... Breaking fundamental invariants like >> "ctid points to this tuple or its update successor" is going to cause >> trouble. There's a lot of code that knows that; more than knows the >> details of

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

Hi, On 2018-03-08 13:46:53 -0500, Tom Lane wrote: > Robert Haas writes: > > On Thu, Mar 8, 2018 at 12:03 PM, Tom Lane wrote: > >> FWIW, I would also vote for (1), especially if the only way to do (2) > >> is stuff as outright scary as this. I would

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On Sat, Mar 17, 2018 at 4:32 PM, Amit Kapila wrote: > On Mon, Mar 12, 2018 at 6:33 PM, amul sul wrote: >> On Mon, Mar 12, 2018 at 11:45 AM, amul sul wrote: >>> On Sat, Mar 10, 2018 at 5:25 PM, Amit Kapila

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On Mon, Mar 12, 2018 at 11:45 AM, amul sul wrote: > On Sat, Mar 10, 2018 at 5:25 PM, Amit Kapila wrote: >> On Fri, Mar 9, 2018 at 3:18 PM, amul sul wrote: >>> On Thu, Mar 8, 2018 at 12:31 PM, Amit Kapila

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On Sat, Mar 10, 2018 at 5:25 PM, Amit Kapila wrote: > On Fri, Mar 9, 2018 at 3:18 PM, amul sul wrote: >> On Thu, Mar 8, 2018 at 12:31 PM, Amit Kapila wrote: >>> On Thu, Mar 8, 2018 at 11:04 AM, Pavan Deolasee >>> This is

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On Fri, Mar 9, 2018 at 3:18 PM, amul sul wrote: > On Thu, Mar 8, 2018 at 12:31 PM, Amit Kapila wrote: >> On Thu, Mar 8, 2018 at 11:04 AM, Pavan Deolasee >> >>> This is just one example. I am almost certain there are many such cases that >>> will

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On Thu, Mar 8, 2018 at 12:31 PM, Amit Kapila wrote: > On Thu, Mar 8, 2018 at 11:04 AM, Pavan Deolasee > wrote: >> >> On Tue, Feb 13, 2018 at 12:41 PM, amul sul wrote: >>> >>> Thanks for the confirmation, updated patch

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

Hi Andres, Thanks for your time and the review comments/suggestions. On Tue, Mar 6, 2018 at 4:53 AM, Andres Freund wrote: > Hi, > > On 2018-02-13 12:41:26 +0530, amul sul wrote: >> From 08c8c7ece7d9411e70a780dbeed89d81419db6b6 Mon Sep 17 00:00:00 2001 >> From: Amul Sul

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On 2018-03-08 14:25:59 -0500, Tom Lane wrote: > Andres Freund writes: > > On March 8, 2018 10:46:53 AM PST, Tom Lane wrote: > >> Breaking fundamental invariants like > >> "ctid points to this tuple or its update successor" is going to cause > >> trouble.

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

Andres Freund writes: > On March 8, 2018 10:46:53 AM PST, Tom Lane wrote: >> Breaking fundamental invariants like >> "ctid points to this tuple or its update successor" is going to cause >> trouble. There's a lot of code that knows that; more than knows

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On March 8, 2018 10:46:53 AM PST, Tom Lane wrote: >Robert Haas writes: >> On Thu, Mar 8, 2018 at 12:03 PM, Tom Lane wrote: >>> FWIW, I would also vote for (1), especially if the only way to do >(2) >>> is stuff as outright scary

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On March 8, 2018 10:46:53 AM PST, Tom Lane wrote: >Robert Haas writes: >> On Thu, Mar 8, 2018 at 12:03 PM, Tom Lane wrote: >>> FWIW, I would also vote for (1), especially if the only way to do >(2) >>> is stuff as outright scary

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On Thu, Mar 8, 2018 at 12:25 PM, Pavan Deolasee wrote: > I think the question is: isn't there an alternate way to achieve the same > result? One alternate way would be to do what I suggested above i.e. free up > more bits and use one of those. That's certainly possible,

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On Thu, Mar 8, 2018 at 10:27 PM, Robert Haas wrote: > > However, there's no such thing as a free lunch. We can't use the CTID > field to point to a CTID in another table because there's no room to > include the identify of the other table in the field. We can't widen >

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On Thu, Mar 8, 2018 at 12:03 PM, Tom Lane wrote: > Robert Haas writes: >> Therefore, the only options are (1) ignore the problem, and let a >> cross-partition update look entirely like a delete+insert, (2) try to >> throw some error in the case where

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

Robert Haas writes: > Therefore, the only options are (1) ignore the problem, and let a > cross-partition update look entirely like a delete+insert, (2) try to > throw some error in the case where this introduces user-visible > anomalies that wouldn't be visible otherwise,

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On Thu, Mar 8, 2018 at 10:07 AM, Tom Lane wrote: > Pavan Deolasee writes: >> I am actually very surprised that 0001-Invalidate-ip_blkid-v5.patch does >> not do anything to deal with the fact that t_ctid may no longer point to >> itself to mark end of

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

Robert Haas writes: > ... I suppose we could still decide that if we > can't have that, we don't want update tuple routing at all, but I > think that's an overreaction. Between this thread and I am

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

Pavan Deolasee writes: > I am actually very surprised that 0001-Invalidate-ip_blkid-v5.patch does > not do anything to deal with the fact that t_ctid may no longer point to > itself to mark end of the chain. I just can't see how that would work. > ... > I am actually

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On Thu, Mar 8, 2018 at 12:34 AM, Pavan Deolasee wrote: > I am actually very surprised that 0001-Invalidate-ip_blkid-v5.patch does not > do anything to deal with the fact that t_ctid may no longer point to itself > to mark end of the chain. I just can't see how that would

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On Thu, Mar 8, 2018 at 3:01 PM, Amit Kapila wrote: > On Thu, Mar 8, 2018 at 12:52 PM, Pavan Deolasee > wrote: >> >> On Thu, Mar 8, 2018 at 12:31 PM, Amit Kapila >> wrote: >>> >>> On Thu, Mar 8, 2018 at 11:04 AM, Pavan

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On Thu, Mar 8, 2018 at 12:52 PM, Pavan Deolasee wrote: > > On Thu, Mar 8, 2018 at 12:31 PM, Amit Kapila > wrote: >> >> On Thu, Mar 8, 2018 at 11:04 AM, Pavan Deolasee >> wrote: >> > >> > On Tue, Feb 13, 2018 at 12:41

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On Thu, Mar 8, 2018 at 12:31 PM, Amit Kapila wrote: > On Thu, Mar 8, 2018 at 11:04 AM, Pavan Deolasee > wrote: > > > > On Tue, Feb 13, 2018 at 12:41 PM, amul sul wrote: > >> > >> Thanks for the confirmation, updated patch

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On 8 March 2018 at 12:34, Amit Kapila wrote: > On Thu, Mar 8, 2018 at 11:57 AM, Amit Khandekar > wrote: >> On 8 March 2018 at 09:15, Pavan Deolasee wrote: >>> For example, with your patches applied: >>> >>> CREATE TABLE

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On Thu, Mar 8, 2018 at 11:57 AM, Amit Khandekar wrote: > On 8 March 2018 at 09:15, Pavan Deolasee wrote: >> For example, with your patches applied: >> >> CREATE TABLE pa_target (key integer, val text) >> PARTITION BY LIST (key); >> CREATE

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On Thu, Mar 8, 2018 at 11:04 AM, Pavan Deolasee wrote: > > On Tue, Feb 13, 2018 at 12:41 PM, amul sul wrote: >> >> Thanks for the confirmation, updated patch attached. >> > > I am actually very surprised that 0001-Invalidate-ip_blkid-v5.patch does not

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On 8 March 2018 at 09:15, Pavan Deolasee wrote: > For example, with your patches applied: > > CREATE TABLE pa_target (key integer, val text) > PARTITION BY LIST (key); > CREATE TABLE part1 PARTITION OF pa_target FOR VALUES IN (1); > CREATE TABLE part2 PARTITION OF

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On Tue, Feb 13, 2018 at 12:41 PM, amul sul wrote: > > Thanks for the confirmation, updated patch attached. > > I am actually very surprised that 0001-Invalidate-ip_blkid-v5.patch does not do anything to deal with the fact that t_ctid may no longer point to itself to mark end

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On Wed, Feb 28, 2018 at 12:38 PM, Rajkumar Raghuwanshi < rajkumar.raghuwan...@enterprisedb.com> wrote: > On Wed, Feb 14, 2018 at 5:44 PM, Amit Kapila > wrote: > >> +# Concurrency error from GetTupleForTrigger >> +# Concurrency error from ExecLockRows >> >> I think you

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On Tue, Mar 6, 2018 at 4:53 AM, Andres Freund wrote: > Hi, > >> diff --git a/src/backend/executor/nodeLockRows.c >> b/src/backend/executor/nodeLockRows.c >> index 7961b4be6a..b07b7092de 100644 >> --- a/src/backend/executor/nodeLockRows.c >> +++

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

Hi, On 2018-02-13 12:41:26 +0530, amul sul wrote: > From 08c8c7ece7d9411e70a780dbeed89d81419db6b6 Mon Sep 17 00:00:00 2001 > From: Amul Sul > Date: Tue, 13 Feb 2018 12:37:52 +0530 > Subject: [PATCH 1/2] Invalidate ip_blkid v5 > > v5: > - Added code in heap_mask to skip

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On Wed, Feb 14, 2018 at 5:44 PM, Amit Kapila wrote: > +# Concurrency error from GetTupleForTrigger > +# Concurrency error from ExecLockRows > > I think you don't need to mention above sentences in spec files. > Apart from that, your patch looks good to me. I have marked

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On Tue, Feb 13, 2018 at 12:41 PM, amul sul wrote: > On Tue, Feb 13, 2018 at 11:32 AM, Amit Kapila wrote: >> >> Your change appears fine to me. I think one can set both block number >> and offset as we do for HeapTupleHeaderIsSpeculative, but the way

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On Tue, Feb 13, 2018 at 11:32 AM, Amit Kapila wrote: > On Wed, Feb 7, 2018 at 6:13 PM, amul sul wrote: >> On Tue, Feb 6, 2018 at 7:05 PM, amul sul wrote: >>> On Sun, Feb 4, 2018 at 10:47 AM, Amit Kapila

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On Wed, Feb 7, 2018 at 6:13 PM, amul sul wrote: > On Tue, Feb 6, 2018 at 7:05 PM, amul sul wrote: >> On Sun, Feb 4, 2018 at 10:47 AM, Amit Kapila wrote: >> >> Yes, you are correct standby stopped with a following error: >> >>

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On Tue, Feb 6, 2018 at 7:05 PM, amul sul wrote: > On Sun, Feb 4, 2018 at 10:47 AM, Amit Kapila wrote: >> On Fri, Feb 2, 2018 at 2:11 PM, amul sul wrote: >>> On Fri, Jan 26, 2018 at 11:58 AM, Amit Kapila

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On Sat, Feb 3, 2018 at 4:04 AM, Robert Haas wrote: > On Fri, Jan 26, 2018 at 1:28 AM, Amit Kapila wrote: >> So, this means that in case of logical replication, it won't generate >> the error this patch is trying to introduce. I think if we want to

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On Tue, Feb 6, 2018 at 7:05 PM, amul sul wrote: > On Sun, Feb 4, 2018 at 10:47 AM, Amit Kapila wrote: >> On Fri, Feb 2, 2018 at 2:11 PM, amul sul wrote: >>> On Fri, Jan 26, 2018 at 11:58 AM, Amit Kapila

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On Sun, Feb 4, 2018 at 10:47 AM, Amit Kapila wrote: > On Fri, Feb 2, 2018 at 2:11 PM, amul sul wrote: >> On Fri, Jan 26, 2018 at 11:58 AM, Amit Kapila >> wrote: >> [] >>> I think you can manually (via debugger) hit this

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On Fri, Feb 2, 2018 at 2:11 PM, amul sul wrote: > On Fri, Jan 26, 2018 at 11:58 AM, Amit Kapila wrote: > [] >> I think you can manually (via debugger) hit this by using >> PUBLICATION/SUBSCRIPTION syntax for logical replication. I think what >>

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On Fri, Jan 26, 2018 at 1:28 AM, Amit Kapila wrote: > So, this means that in case of logical replication, it won't generate > the error this patch is trying to introduce. I think if we want to > handle this we need some changes in WAL and logical decoding as well. > >

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

Hi Amit, Sorry for the delayed response. On Fri, Jan 26, 2018 at 11:58 AM, Amit Kapila wrote: > On Wed, Jan 24, 2018 at 12:44 PM, amul sul wrote: >> On Tue, Jan 23, 2018 at 7:01 PM, Amit Kapila wrote: >>> On Fri, Jan 12,

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On Wed, Jan 24, 2018 at 12:44 PM, amul sul wrote: > On Tue, Jan 23, 2018 at 7:01 PM, Amit Kapila wrote: >> On Fri, Jan 12, 2018 at 11:43 AM, amul sul wrote: > [] >> I have asked to change the message "tuple to be updated .."

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On Tue, Jan 23, 2018 at 7:01 PM, Amit Kapila wrote: > On Fri, Jan 12, 2018 at 11:43 AM, amul sul wrote: [] > I have asked to change the message "tuple to be updated .." after > heap_lock_tuple call not in nodeModifyTable.c, so please revert the >

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On Fri, Jan 12, 2018 at 11:43 AM, amul sul wrote: > > Thanks for looking at this thread, attached herewith an updated patch rebase > on > 'UPDATE of partition key v35' patch[1]. > ExecDelete(mtstate, tupleid, oldtuple, planSlot, epqstate, estate, - _deleted, false,

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On Thu, Jan 11, 2018 at 8:06 PM, Stephen Frost wrote: > Amul, > > * amul sul (sula...@gmail.com) wrote: >> Agree, updated in the attached patch. Patch 0001 also includes your >> previous review comment[1] and typo correction suggested by Alvaro[2]. > > Looks like this needs

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

Amul, * amul sul (sula...@gmail.com) wrote: > Agree, updated in the attached patch. Patch 0001 also includes your > previous review comment[1] and typo correction suggested by Alvaro[2]. Looks like this needs to be rebased (though the failures aren't too bad, from what I'm seeing), so going to

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On Wed, Nov 29, 2017 at 7:51 AM, Amit Kapila wrote: > On Tue, Nov 28, 2017 at 5:58 PM, amul sul wrote: >> On Sat, Nov 25, 2017 at 11:39 AM, Amit Kapila >> wrote: >>> On Thu, Nov 23, 2017 at 5:18 PM, amul sul

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On Tue, Nov 28, 2017 at 5:58 PM, amul sul wrote: > On Sat, Nov 25, 2017 at 11:39 AM, Amit Kapila wrote: >> On Thu, Nov 23, 2017 at 5:18 PM, amul sul wrote: >>> On Sat, Nov 11, 2017 at 1:05 AM, Robert Haas

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On Fri, Nov 24, 2017 at 9:37 PM, Alvaro Herrera wrote: > A typo in all the messages the patch adds: > "to an another" -> "to another" > Thanks for the looking into the patch, will fix in the next version. Regards, Amul

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On Sat, Nov 25, 2017 at 11:39 AM, Amit Kapila wrote: > On Thu, Nov 23, 2017 at 5:18 PM, amul sul wrote: >> On Sat, Nov 11, 2017 at 1:05 AM, Robert Haas wrote: >>> On Wed, Sep 27, 2017 at 7:07 AM, amul sul

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On Thu, Nov 23, 2017 at 5:18 PM, amul sul wrote: > On Sat, Nov 11, 2017 at 1:05 AM, Robert Haas wrote: >> On Wed, Sep 27, 2017 at 7:07 AM, amul sul wrote: >>> Attaching POC patch that throws an error in the case of a concurrent update

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

A typo in all the messages the patch adds: "to an another" -> "to another" -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On Thu, Nov 23, 2017 at 6:48 AM, amul sul wrote: > And remaining are EvalPlanQualFetch, ExecOnConflictUpdate, > RelationFindReplTupleByIndex & RelationFindReplTupleSeq. Note that check in > RelationFindReplTupleByIndex & RelationFindReplTupleSeq will have LOG not an > ERROR.

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On Sat, Nov 11, 2017 at 1:05 AM, Robert Haas wrote: > On Wed, Sep 27, 2017 at 7:07 AM, amul sul wrote: >> Attaching POC patch that throws an error in the case of a concurrent update >> to an already deleted tuple due to UPDATE of partition key[1]. >> >>