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. I've
> pushed the patch
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 EvalPlanQ
On 2018-04-06 09:41:07 +0530, Amit Kapila wrote:
> >> Won't the same question applies to the similar usage in
> >> EvalPlanQualFetch and heap_lock_updated_tuple_rec.
> >
> > I don't think so?
> >
> >
> >> In EvalPlanQualFetch, we consider such a tuple to be deleted and will
> >> silently miss/skip
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 explained above further com
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 spent a good chunk of
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 [
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(&hufd.ctid))
> + ereport(ERROR,
> + (errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
> + errmsg("tuple to be lock
On Fri, Apr 6, 2018 at 12:50 PM, amul sul wrote:
>
> Updated patch attached.
>
+ if (ItemPointerIndicatesMovedPartitions(&hufd.ctid))
+ ereport(ERROR,
+ (errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
+ errmsg("tuple to be locked was already moved to another partition
due to concurrent update
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 the "moved" information not being crash-sa
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
>>> "tuple to be locked was already moved to another partition du
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
>> concurrent update"
>> as the error message. If som
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 at the top of the function, now if no row
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 at the top of the function, now if no row
> version is visible, then it should have the same value as
Pavan Deolasee wrote:
> On Thu, Apr 5, 2018 at 7:14 AM, Andres Freund wrote:
> + /*
> +* 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 tuple to
> +* be lock is moved to anot
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 to be locked was already moved to another parti
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 tuple
to
+
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 happy with
>> > "tuple to be locked was already moved to another partitio
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 update"
> > as the error message. If somebody
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 bit in the ctid from
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 later tuple in the chai
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
>> >> b/src/backend/executor/nodeLockRows.c
>> >> index 7961b4be6a.
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
> >> --- a/src/backend/executor/nodeLockRow
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
> code won't realize it sh
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 inclined to see a huge is
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 what's in xmax, I believe
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 far rather have (3) than
> >> this, because IM
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
>>> wrote:
complete CTID.
>>>
>>> Sure, will do that.
>>
>> I did the aforementioned
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 wrote:
>>> complete CTID.
>>
>> Sure, will do that.
>
> I did the aforementioned changes in the attached patch, thanks.
>
--- a/src/include/storag
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
>>> wrote:
On Thu, Mar 8, 2018 at 11:04 AM, Pavan Deolasee
> This is just on
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 just one example. I am almost certain there are many such cases
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 require careful attention.
>>>
>>
>> Right, I think
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 attached.
>>>
>>
>> I am actually very surprised that 0001-Invalidate-ip_blkid
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
>> Date: Tue, 13 Feb 2018
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. There's a lot of code that knows that; mo
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 the
>> details of what's in xmax, I believ
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 as this. I would far rather have (3)
>than
>>> this, because IMO
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 as this. I would far rather have (3)
>than
>>> this, because IMO
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 far rather have (3) than
>> this, because IMO, what we are looking at right now is going to make
>> the f
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, but TBH the CTID field see
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
> it to make room because t
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 this introduces user-visible
>> anomalies that
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, or (3) revert update
> t
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 the chain. I just can't see how that would wor
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 getting the distinct impression that that feature wasn't ready
to be committed. I think that reve
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 worried that we're tinkering w
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 work. But if it
> does, it
On Thu, Mar 8, 2018 at 12:31 PM, Amit Kapila wrote:
> On Thu, Mar 8, 2018 at 11:04 AM, Pavan Deolasee
> wrote:
>>
[.]
>
>> But if it
>> does, it needs good amount of comments explaining why and most likely
>> updating comments at other places where chain following is done. For
>> example, how
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 Deolasee
>>> wrote:
>>> >
>>> > On Tue, Feb 13, 2018 at 12:41 PM, amul sul w
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 PM, amul sul wrote:
>> >>
>> >> Thanks for the confirmation, updated patch att
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 attached.
> >>
> >
> > I am actually very surprised that 0001-Invalidate-
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 pa_target (key integer, val text)
>>> PARTITION BY LIST (key);
>>> CREA
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 TABLE part1 PARTITION OF pa_target FOR VALUES IN (1);
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
> do anything to deal with the fact that t_ct
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 pa_target FOR VALUES IN (2);
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 of the chain. I just
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 don't need to mention above
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
>> +++ b/src/backend/executor/nodeLockRows.c
>> @@ -218,6 +
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 wal_consistency_checking[
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 it as
> Ready For Committ
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 you
>> have done it looks good to me. Kindly
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
>>> wrote:
>>>
>>> Yes, you are correct standby stopped with a following error:
>>>
>>> FA
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:
>>
>> FATAL: inconsistent page found, rel 1663/13260/16390, forknum 0, blk
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
>>> wrote:
[]
>>
>> I wonder what will be the behavior of this patch with
>> wal_consis
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
>> handle this we need some changes in WAL and l
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
>>> wrote:
>>> []
I think you can manually (via debugger) hit this by using
P
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 by using
>>> PUBLICATION/SUBSCRIPTION syntax for logical replication.
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
>> you need to do is in node-1, create a partition
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.
>
> Robert, others, what do you
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, 2018 at 11:43 AM, amul sul wrote:
[]
> I think you can manually (via
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 .." after
>> heap_lock_tuple call not in nodeModifyTable.c, so please r
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
> message in nodeModifyTable.c.
>
Understood, f
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,
- &tuple_deleted, false, false);
+ &tuple_d
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 to be rebased (though
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 m
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 wrote:
On Sat, Nov 11, 2017 at 1:05 AM, Robert Haas wrote:
> On Wed, Sep 27,
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 wrote:
On Wed, Sep 27, 2017 at 7:07 AM, amul sul wrote:
>
> [...]
>> Few comment
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
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 wrote:
[...]
> Few comments:
>
Thanks for looking at the patch, please find my commen
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
>>> to an already deleted tuple due to UPDATE of partition ke
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
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.
The first one is goi
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].
>>
>> In a normal update new tuple is linked to t
82 matches
Mail list logo
