Hi Maksim,
On 2017/04/07 19:52, Maksim Milyutin wrote:
On 07.04.2017 13:05, Etsuro Fujita wrote:
On 2016/12/09 19:46, Maksim Milyutin wrote:
I would like to work on two tasks:
- insert (and eventually update) tuple routing for foreign partition.
- the ability to create an index on the pare
On Wed, May 10, 2017 at 6:50 AM, Etsuro Fujita
wrote:
> I started working on this. I agree that the changes made in
> make_modifytable would be unacceptable, but I'd vote for Amit's idea of
> passing a modified PlannerInfo to PlanForeignModify so that the FDW can do
> query planning for INSERT in
On 2016/11/18 1:43, Robert Haas wrote:
On Thu, Nov 17, 2016 at 6:27 AM, Amit Langote
wrote:
- The code in make_modifytable() to swap out the rte_array for a fake
one looks like an unacceptable kludge. I don't know offhand what a
better design would look like, but what you've got is really ug
On 2017/05/10 12:59, Robert Haas wrote:
> On Tue, May 9, 2017 at 11:54 PM, Thomas Munro
> wrote:
>> +A statement that targets a parent table in a inheritance or partitioning
>>
>> A tiny typo: s/a inheritance/an inheritance/
>
> Now he tells me.
Thanks both.
Regards,
Amit
--
Sent via pg
On Tue, May 9, 2017 at 11:54 PM, Thomas Munro
wrote:
> +A statement that targets a parent table in a inheritance or partitioning
>
> A tiny typo: s/a inheritance/an inheritance/
Now he tells me.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
On Wed, May 10, 2017 at 3:51 PM, Robert Haas wrote:
> On Sun, May 7, 2017 at 9:44 PM, Amit Langote
> wrote:
>> I think that makes sense. Modified it to read: "A statement that targets
>> a parent table in a inheritance or partitioning hierarchy..." in the
>> attached updated patch.
>
> LGTM. Co
On Sun, May 7, 2017 at 9:44 PM, Amit Langote
wrote:
> I think that makes sense. Modified it to read: "A statement that targets
> a parent table in a inheritance or partitioning hierarchy..." in the
> attached updated patch.
LGTM. Committed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb
On 2017/05/08 10:22, Thomas Munro wrote:
> On Mon, May 8, 2017 at 12:47 PM, Amit Langote
> wrote:
>> On 2017/05/03 2:48, Robert Haas wrote:
>>> On Tue, May 2, 2017 at 3:30 AM, Amit Langote
>>> wrote:
You're right. I agree that whatever text we add here should be pointing
out that state
On Mon, May 8, 2017 at 12:47 PM, Amit Langote
wrote:
> On 2017/05/03 2:48, Robert Haas wrote:
>> On Tue, May 2, 2017 at 3:30 AM, Amit Langote
>> wrote:
>>> You're right. I agree that whatever text we add here should be pointing
>>> out that statement-level triggers of affected child tables are n
On 2017/05/03 2:48, Robert Haas wrote:
> On Tue, May 2, 2017 at 3:30 AM, Amit Langote
> wrote:
>> You're right. I agree that whatever text we add here should be pointing
>> out that statement-level triggers of affected child tables are not fired,
>> when root parent is specified in the command.
>
On Tue, May 2, 2017 at 3:30 AM, Amit Langote
wrote:
> You're right. I agree that whatever text we add here should be pointing
> out that statement-level triggers of affected child tables are not fired,
> when root parent is specified in the command.
>
> Since there was least some talk of changing
On 2017/05/01 21:30, Robert Haas wrote:
> On Mon, May 1, 2017 at 12:18 AM, Amit Langote
> wrote:
>> Attached updated patch.
>
> Committed, except for this bit:
Thanks.
> +A statement-level trigger defined on partitioned tables is fired only
> +once for the table itself, not once for eve
On Mon, May 1, 2017 at 12:18 AM, Amit Langote
wrote:
> Attached updated patch.
Committed, except for this bit:
+A statement-level trigger defined on partitioned tables is fired only
+once for the table itself, not once for every table in the partitioning
+hierarchy. However, row-lev
On 2017/04/29 6:56, David Fetter wrote:
> On Fri, Apr 28, 2017 at 06:29:48PM +0900, Amit Langote wrote:
>> On 2017/04/28 7:36, David Fetter wrote:
>>> Did I notice correctly that there's no way to handle transition tables
>>> for partitions in AFTER STATEMENT triggers?
>>
>> Did you mean to ask abo
Thanks for the review.
On 2017/04/29 1:25, Robert Haas wrote:
> On Fri, Apr 28, 2017 at 2:13 AM, Amit Langote
> wrote:
By the way, code changes I made in the attached are such that a subsequent
patch could implement firing statement-level triggers of all the tables in
a partition
On Mon, Apr 24, 2017 at 07:43:29PM +0900, Amit Langote wrote:
> On 2017/04/21 17:00, Rajkumar Raghuwanshi wrote:
> > I am able to create statement triggers at root partition, but these
> > triggers, not getting fired on updating partition.
> It would be great if you could check if the patches fix
On Fri, Apr 28, 2017 at 06:29:48PM +0900, Amit Langote wrote:
> On 2017/04/28 7:36, David Fetter wrote:
> > On Thu, Apr 27, 2017 at 10:30:54AM +0900, Amit Langote wrote:
> >> On 2017/04/27 1:52, Robert Haas wrote:
> >>> On Tue, Apr 25, 2017 at 10:34 PM, Amit Langote
> >>> wrote:
> FWIW, I too
On Fri, Apr 28, 2017 at 2:13 AM, Amit Langote
wrote:
> It seems to me that there is no difference in behavior between
> inheritance-based and declarative partitioning as far as statement-level
> triggers are concerned (at least currently). In both the cases, we fire
> statement-level triggers on
On 2017/04/28 7:36, David Fetter wrote:
> On Thu, Apr 27, 2017 at 10:30:54AM +0900, Amit Langote wrote:
>> On 2017/04/27 1:52, Robert Haas wrote:
>>> On Tue, Apr 25, 2017 at 10:34 PM, Amit Langote
>>> wrote:
FWIW, I too prefer the latter, that is, fire only the parent's triggers.
In that
Hi Rajkumar,
On 2017/04/28 17:11, Rajkumar Raghuwanshi wrote:
> On Fri, Apr 28, 2017 at 11:43 AM, Amit Langote <
>> Updated patch attached.
>
> I have applied given patch, could see below behaviour with statement
> trigger.
>
> When trying to delete value within partition range, triggers got fir
On Fri, Apr 28, 2017 at 11:43 AM, Amit Langote <
langote_amit...@lab.ntt.co.jp> wrote:
> Updated patch attached.
>
Hi Amit,
I have applied given patch, could see below behaviour with statement
trigger.
When trying to delete value within partition range, triggers got fired
(with zero row affecte
Thanks for taking a look.
On 2017/04/28 5:24, Robert Haas wrote:
> On Wed, Apr 26, 2017 at 9:30 PM, Amit Langote
> wrote:
>>> Do we need to update the documentation?
>>
>> Yes, I think we should. How about as in the attached?
>
> Looks reasonable, but I was thinking you might also update the se
On Thu, Apr 27, 2017 at 10:30:54AM +0900, Amit Langote wrote:
> On 2017/04/27 1:52, Robert Haas wrote:
> > On Tue, Apr 25, 2017 at 10:34 PM, Amit Langote
> > wrote:
> >> FWIW, I too prefer the latter, that is, fire only the parent's triggers.
> >> In that case, applying only the patch 0001 will do
On Wed, Apr 26, 2017 at 9:30 PM, Amit Langote
wrote:
>> Do we need to update the documentation?
>
> Yes, I think we should. How about as in the attached?
Looks reasonable, but I was thinking you might also update the section
which contrasts inheritance-based partitioning with declarative
partiti
On 2017/04/27 1:52, Robert Haas wrote:
> On Tue, Apr 25, 2017 at 10:34 PM, Amit Langote
> wrote:
>> FWIW, I too prefer the latter, that is, fire only the parent's triggers.
>> In that case, applying only the patch 0001 will do.
>
> Do we need to update the documentation?
Yes, I think we should.
On Tue, Apr 25, 2017 at 10:34 PM, Amit Langote
wrote:
> FWIW, I too prefer the latter, that is, fire only the parent's triggers.
> In that case, applying only the patch 0001 will do.
Do we need to update the documentation?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise
On 26 April 2017 at 00:28, Robert Haas wrote:
> So what I'd prefer -- on
> the totally unprincipled basis that it would let us improve
> performance in the future -- if you operate on a partition directly,
> you fire the partition's triggers, but if you operate on the parent,
> only the parent's t
Hi,
Thanks for testing.
On 2017/04/25 19:03, Rajkumar Raghuwanshi wrote:
> Thanks for looking into it. I have applied fixes and checked for triggers.
> I could see difference in behaviour of statement triggers for INSERT and
> UPDATE, for insert only root partition triggers are getting fired but
On 2017/04/26 3:58, Robert Haas wrote:
> On Mon, Apr 24, 2017 at 6:43 AM, Amit Langote
> wrote:
>> The reason it doesn't work is that we do not allocate ResultRelInfos for
>> partitioned tables (not even for the root partitioned table in the
>> update/delete cases), because the current implementat
On Mon, Apr 24, 2017 at 6:43 AM, Amit Langote
wrote:
> The reason it doesn't work is that we do not allocate ResultRelInfos for
> partitioned tables (not even for the root partitioned table in the
> update/delete cases), because the current implementation assumes they are
> not required. That's f
On Mon, Apr 24, 2017 at 4:13 PM, Amit Langote wrote:
> Hi Rajkumar,
>
> It would be great if you could check if the patches fix the issues.
>
Hi Amit,
Thanks for looking into it. I have applied fixes and checked for triggers.
I could see difference in behaviour of statement triggers for INSERT
Hi Rajkumar,
Thanks for testing and the report.
On 2017/04/21 17:00, Rajkumar Raghuwanshi wrote:
> Hi,
>
> I have observed below with the statement triggers.
>
> I am able to create statement triggers at root partition, but these
> triggers, not getting fired on updating partition.
>
> CREATE
Hi,
I have observed below with the statement triggers.
I am able to create statement triggers at root partition, but these
triggers, not getting fired on updating partition.
CREATE TABLE pt (a INT, b INT) PARTITION BY RANGE(a);
CREATE TABLE pt1 PARTITION OF pt FOR VALUES FROM (1) to (7);
CREATE
On 07.04.2017 13:05, Etsuro Fujita wrote:
On 2016/12/14 16:20, Etsuro Fujita wrote:
On 2016/12/09 19:46, Maksim Milyutin wrote:
I would like to work on two tasks:
- insert (and eventually update) tuple routing for foreign partition.
- the ability to create an index on the parent and have all
On 2016/12/14 16:20, Etsuro Fujita wrote:
On 2016/12/09 19:46, Maksim Milyutin wrote:
I would like to work on two tasks:
- insert (and eventually update) tuple routing for foreign partition.
- the ability to create an index on the parent and have all of the
children inherit it;
The first one
Hi Amit,
On Thu, 23 Feb 2017 16:29:32 +0900
Amit Langote wrote:
> Thanks for taking care of that.
>
> + * PartitionRoot relation descriptor for parent
> relation
>
> Maybe: relation descriptor for root parent relation
This seems better. Patch is updated.
Thanks,
Nagata-san,
On 2017/02/23 16:17, Yugo Nagata wrote:
> Hi,
>
> I found that a comment for PartitionRoot in ResultRelInfo is missing.
> Although this is trivial, since all other members have comments, I
> think it is needed. Attached is the patch to fix it.
Thanks for taking care of that.
+ *
Hi,
I found that a comment for PartitionRoot in ResultRelInfo is missing.
Although this is trivial, since all other members have comments, I
think it is needed. Attached is the patch to fix it.
Regards,
Yugo Nagata
On Tue, 27 Dec 2016 17:59:05 +0900
Amit Langote wrote:
> On 2016/12/26 19:46, A
On Fri, Feb 10, 2017 at 12:54 AM, Amit Langote
wrote:
> On 2017/02/09 15:22, amul sul wrote:
>> About 0001-Check-partition-strategy-in-ATExecDropNotNull.patch,
>> following test is already covered in alter_table.sql @ Line # 1918,
>> instead of this kindly add test for list_partition:
>>
>> 77 +-
On 2017/02/09 15:22, amul sul wrote:
> About 0001-Check-partition-strategy-in-ATExecDropNotNull.patch,
> following test is already covered in alter_table.sql @ Line # 1918,
> instead of this kindly add test for list_partition:
>
> 77 +-- cannot drop NOT NULL constraint of a range partition key co
About 0001-Check-partition-strategy-in-ATExecDropNotNull.patch,
following test is already covered in alter_table.sql @ Line # 1918,
instead of this kindly add test for list_partition:
77 +-- cannot drop NOT NULL constraint of a range partition key column
78 +ALTER TABLE range_parted ALTER a DROP
On 2017/02/08 21:20, amul sul wrote:
> Regarding following code in ATExecDropNotNull function, I don't see
> any special check for RANGE partitioned, is it intended to have same
> restriction for LIST partitioned too, I guess not?
>
> /*
> * If the table is a range partitioned table, check
Hi Amit,
Regarding following code in ATExecDropNotNull function, I don't see
any special check for RANGE partitioned, is it intended to have same
restriction for LIST partitioned too, I guess not?
/*
* If the table is a range partitioned table, check that the column is not
* in the pa
On Mon, Jan 30, 2017 at 4:42 PM, Peter Eisentraut
wrote:
> On 1/25/17 12:54 AM, Ashutosh Bapat wrote:
>> The documentation available at
>> https://www.postgresql.org/docs/devel/static/sql-createtable.html,
>> does not make it clear that the lower bound of a range partition is
>> always inclusive a
On 2017/01/31 6:42, Peter Eisentraut wrote:
> On 1/25/17 12:54 AM, Ashutosh Bapat wrote:
>> The documentation available at
>> https://www.postgresql.org/docs/devel/static/sql-createtable.html,
>> does not make it clear that the lower bound of a range partition is
>> always inclusive and the higher
On 1/25/17 12:54 AM, Ashutosh Bapat wrote:
> The documentation available at
> https://www.postgresql.org/docs/devel/static/sql-createtable.html,
> does not make it clear that the lower bound of a range partition is
> always inclusive and the higher one is exclusive. I think a note in
> section " PA
Hi Ashutosh,
On 2017/01/25 14:54, Ashutosh Bapat wrote:
> The documentation available at
> https://www.postgresql.org/docs/devel/static/sql-createtable.html,
> does not make it clear that the lower bound of a range partition is
> always inclusive and the higher one is exclusive. I think a note in
The documentation available at
https://www.postgresql.org/docs/devel/static/sql-createtable.html,
does not make it clear that the lower bound of a range partition is
always inclusive and the higher one is exclusive. I think a note in
section " PARTITION OF parent_table FOR VALUES partition_bound_sp
On 2017/01/25 5:55, Robert Haas wrote:
> On Thu, Jan 19, 2017 at 9:58 PM, Amit Langote
> wrote:
>> [ new patches ]
>
> Committed 0001 and 0002. See my earlier email for comments on 0003.
It seems patches for all the issues mentioned in this thread so far,
except 0003 (I just sent an updated ver
On 2017/01/25 2:56, Robert Haas wrote:
> On Thu, Jan 19, 2017 at 9:58 PM, Amit Langote
> wrote:
>>> But I wonder why we don't instead just change this function to
>>> consider tdhasoid rather than tdtypeid. I mean, if the only point of
>>> comparing the type OIDs is to find out whether the table-
Hi Keith,
On 2017/01/20 12:40, Keith Fiske wrote:
> So testing things out in pg_partman for native sub-partitioning and ran
> into what is a bug for me that I know I have to fix, but I'm curious if
> this can be prevented in the first place within the native partitioning
> code itself. The below s
On Thu, Jan 19, 2017 at 9:58 PM, Amit Langote
wrote:
> [ new patches ]
Committed 0001 and 0002. See my earlier email for comments on 0003.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgre
On Thu, Jan 19, 2017 at 9:58 PM, Amit Langote
wrote:
>> But I wonder why we don't instead just change this function to
>> consider tdhasoid rather than tdtypeid. I mean, if the only point of
>> comparing the type OIDs is to find out whether the table-has-OIDs
>> setting matches, we could instead
On 2017/01/21 6:29, Robert Haas wrote:
> On Fri, Jan 20, 2017 at 1:15 AM, Andres Freund wrote:
>> On 2017-01-19 14:18:23 -0500, Robert Haas wrote:
>>> Committed.
>>
>> One of the patches around this topic committed recently seems to cause
>> valgrind failures like
>> https://buildfarm.postgresql.o
On Fri, Jan 20, 2017 at 1:15 AM, Andres Freund wrote:
> On 2017-01-19 14:18:23 -0500, Robert Haas wrote:
>> Committed.
>
> One of the patches around this topic committed recently seems to cause
> valgrind failures like
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink&dt=2017-01-19%2
Hi Andres,
On 2017/01/20 15:15, Andres Freund wrote:
> On 2017-01-19 14:18:23 -0500, Robert Haas wrote:
>> Committed.
>
> One of the patches around this topic committed recently seems to cause
> valgrind failures like
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink&dt=2017-01-19%2
On 2017-01-19 14:18:23 -0500, Robert Haas wrote:
> Committed.
One of the patches around this topic committed recently seems to cause
valgrind failures like
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink&dt=2017-01-19%2008%3A40%3A02
:
==24969== Conditional jump or move depends on uni
So testing things out in pg_partman for native sub-partitioning and ran
into what is a bug for me that I know I have to fix, but I'm curious if
this can be prevented in the first place within the native partitioning
code itself. The below shows a sub-partitioning set where the sub-partition
has a c
On 2017/01/20 4:18, Robert Haas wrote:
> On Thu, Jan 19, 2017 at 12:15 AM, Amit Langote wrote:
>> 0002-Set-ecxt_scantuple-correctly-for-tuple-routing.patch
>>
>> In 2ac3ef7a01df859c62d0a02333b646d65eaec5ff, we changed things so that
>> it's possible for a different TupleTableSlot to be used for par
On Thu, Jan 19, 2017 at 12:15 AM, Amit Langote
wrote:
> 0001-Fix-a-bug-of-insertion-into-an-internal-partition.patch
>
> Since implicit partition constraints are not inherited, an internal
> partition's constraint was not being enforced when targeted directly.
> So, include such constraint when se
On 2017/01/19 14:15, Amit Langote wrote:
> So, here are all the patches I posted to date (and one new at the bottom)
> for reported and unreported bugs, excluding the one involving
> BulkInsertState for which you replied in a new thread.
>
> I'll describe the attached patches in brief:
Sorry, I f
On 2017/01/19 5:29, Robert Haas wrote:
> On Wed, Jan 18, 2017 at 3:12 PM, Robert Haas wrote:
>> On Tue, Jan 10, 2017 at 6:06 AM, Amit Langote
>> wrote:
>>> [ updated patches ]
>>
>> I committed 0004 and also fixed the related regression test not to
>> rely on DROP .. CASCADE, which isn't always s
On Wed, Jan 18, 2017 at 3:12 PM, Robert Haas wrote:
> On Tue, Jan 10, 2017 at 6:06 AM, Amit Langote
> wrote:
>> [ updated patches ]
>
> I committed 0004 and also fixed the related regression test not to
> rely on DROP .. CASCADE, which isn't always stable. The remainder of
> this patch set needs
On Tue, Jan 10, 2017 at 6:06 AM, Amit Langote
wrote:
> [ updated patches ]
I committed 0004 and also fixed the related regression test not to
rely on DROP .. CASCADE, which isn't always stable. The remainder of
this patch set needs a rebase, and perhaps you could also fold in
other pending parti
On Mon, Jan 16, 2017 at 4:09 AM, Amit Langote
wrote:
> The problem is that whereas the SlotValueDescription that we build to show
> in the error message should be based on the tuple that was passed to
> ExecInsert() or whatever NextCopyFrom() returned for CopyFrom() to
> process, it might fail to
On 2017/01/14 6:24, Robert Haas wrote:
> On Tue, Jan 10, 2017 at 6:06 AM, Amit Langote wrote:
>>
>> Thanks! I realized however that the approach I used in 0002 of passing
>> the original slot to ExecConstraints() fails in certain situations. For
>> example, if a BR trigger changes the tuple, the
On Tue, Jan 10, 2017 at 6:06 AM, Amit Langote
wrote:
> On 2017/01/05 5:50, Robert Haas wrote:
>> On Tue, Dec 27, 2016 at 3:59 AM, Amit Langote
>> wrote:
>>> Patches 0001 to 0006 unchanged.
>>
>> Committed 0001 earlier, as mentioned in a separate email. Committed
>> 0002 and part of 0003.
>
> Tha
On 2017/01/06 20:23, Amit Langote wrote:
> On 2017/01/05 3:26, Robert Haas wrote:
>> It's unclear to me why we need to do 0002. It doesn't seem like it
>> should be necessary, it doesn't seem like a good idea, and the commit
>> message you proposed is uninformative.
>
> If a single BulkInsertState
On 2017/01/05 5:50, Robert Haas wrote:
> On Tue, Dec 27, 2016 at 3:59 AM, Amit Langote
> wrote:
>> Patches 0001 to 0006 unchanged.
>
> Committed 0001 earlier, as mentioned in a separate email. Committed
> 0002 and part of 0003.
Thanks! I realized however that the approach I used in 0002 of pass
Hi Kieth,
On 2017/01/10 14:44, Keith Fiske wrote:
> Is there any reason for the exclusion of parent tables from the pg_tables
> system catalog view? They do not show up in information_schema.tables as
> well. I believe I found where to make the changes and I tested to make sure
> it works for my
Hi Amul,
On 2017/01/09 17:29, amul sul wrote:
> I got server crash due to assert failure at ATTACHing overlap rang
> partition, here is test case to reproduce this:
>
> CREATE TABLE test_parent(a int) PARTITION BY RANGE (a);
> CREATE TABLE test_parent_part2 PARTITION OF test_parent FOR VALUES
>
Is there any reason for the exclusion of parent tables from the pg_tables
system catalog view? They do not show up in information_schema.tables as
well. I believe I found where to make the changes and I tested to make sure
it works for my simple case. Attached is my first attempt at patching
anythi
Hi,
I got server crash due to assert failure at ATTACHing overlap rang
partition, here is test case to reproduce this:
CREATE TABLE test_parent(a int) PARTITION BY RANGE (a);
CREATE TABLE test_parent_part2 PARTITION OF test_parent FOR VALUES
FROM(100) TO(200);
CREATE TABLE test_parent_part1(a int
On 2017/01/05 3:26, Robert Haas wrote:
> On Tue, Dec 27, 2016 at 8:41 PM, Amit Langote
> wrote:
>> On 2016/12/27 19:07, Amit Langote wrote:
>>> Attached should fix that.
>>
>> Here are the last two patches with additional information like other
>> patches. Forgot to do that yesterday.
>
> 0001 h
Hi Keith,
On 2017/01/06 2:16, Keith Fiske wrote:
> Could we get some clarification on the partition_bound_spec portion of the
> PARTITION OF clause? Just doing some testing it seems it's inclusive of the
> FROM value but exclusive of the TO value. I don't see mention of this in
> the docs as of c
Could we get some clarification on the partition_bound_spec portion of the
PARTITION OF clause? Just doing some testing it seems it's inclusive of the
FROM value but exclusive of the TO value. I don't see mention of this in
the docs as of commit 18fc5192a631441a73e6a3b911ecb14765140389 yesterday.
I
On 2016/12/14 12:14, Venkata B Nagothi wrote:
> Loading the data into a normal table is not an issue (infact the csv is
> generated from the table itself)
>
> The issue is occurring only when i am trying to load the data from CSV file
> into a partitioned table -
>
> db01=# CREATE TABLE orders_y1
On Tue, Dec 27, 2016 at 3:59 AM, Amit Langote
wrote:
> Patches 0001 to 0006 unchanged.
Committed 0001 earlier, as mentioned in a separate email. Committed
0002 and part of 0003. But I'm skeptical that the as-patched-by-0003
logic in generate_partition_qual() makes sense. You do this:
On Tue, Dec 27, 2016 at 8:41 PM, Amit Langote
wrote:
> On 2016/12/27 19:07, Amit Langote wrote:
>> Attached should fix that.
>
> Here are the last two patches with additional information like other
> patches. Forgot to do that yesterday.
0001 has the disadvantage that get_partition_for_tuple() a
On Mon, Dec 26, 2016 at 5:46 AM, Amit Langote
wrote:
> On 2016/12/23 8:08, Robert Haas wrote:
>> On Thu, Dec 22, 2016 at 3:35 AM, Amit Langote
>> wrote:
>>> While working on that, I discovered yet-another-bug having to do with the
>>> tuple descriptor that's used as we route a tuple down a partit
On 2017/01/04 16:31, 高增琦 wrote:
> Server crash(failed assertion) when two "insert" in one SQL:
>
> Step to reproduce:
> create table t(a int, b int) partition by range(a);
> create table t_p1 partition of t for values from (1) to (100);
> create table t_p2 partition of t for values from (100) to (
Server crash(failed assertion) when two "insert" in one SQL:
Step to reproduce:
create table t(a int, b int) partition by range(a);
create table t_p1 partition of t for values from (1) to (100);
create table t_p2 partition of t for values from (100) to (200);
create table t_p3 partition of t for v
On Wed, Jan 4, 2017 at 10:37 AM, Amit Langote wrote:
> On 2017/01/03 19:04, Rajkumar Raghuwanshi wrote:
> > On Tue, Dec 27, 2016 at 3:24 PM, Amit Langote wrote:
> >>
> >> Attached patch should fix the same.
> >
> > I have applied attached patch, server crash for range is fixed, but still
> > gett
On 2017/01/03 19:04, Rajkumar Raghuwanshi wrote:
> On Tue, Dec 27, 2016 at 3:24 PM, Amit Langote wrote:
>>
>> Attached patch should fix the same.
>
> I have applied attached patch, server crash for range is fixed, but still
> getting crash for multi-level list partitioning insert.
>
> postgres=#
On Tue, Dec 27, 2016 at 3:24 PM, Amit Langote wrote:
> On 2016/12/27 18:30, Rajkumar Raghuwanshi wrote:
> > Hi Amit,
> >
> > I have pulled latest sources from git and tried to create multi-level
> > partition, getting a server crash, below are steps to reproduce. please
> > check if it is reprod
On 2016/12/27 19:07, Amit Langote wrote:
> Attached should fix that.
Here are the last two patches with additional information like other
patches. Forgot to do that yesterday.
Thanks,
Amit
>From 5a82b4caa6cec7845eb48e0397fab49c74b8dd98 Mon Sep 17 00:00:00 2001
From: amit
Date: Wed, 28 Dec 2016
On 2016/12/27 18:48, 高增琦 wrote:
> Hi ,
>
> I tried "COPY FROM" in the git version. It inserts rows to wrong partition.
>
> step to reproduce:
> create table t(a int, b int) partition by range(a);
> create table t_p1 partition of t for values from (1) to (100);
> create table t_p2 partition of t
On 2016/12/27 18:30, Rajkumar Raghuwanshi wrote:
> Hi Amit,
>
> I have pulled latest sources from git and tried to create multi-level
> partition, getting a server crash, below are steps to reproduce. please
> check if it is reproducible in your machine also.
>
[ ... ]
> postgres=# INSERT INTO
Hi ,
I tried "COPY FROM" in the git version. It inserts rows to wrong partition.
step to reproduce:
create table t(a int, b int) partition by range(a);
create table t_p1 partition of t for values from (1) to (100);
create table t_p2 partition of t for values from (100) to (200);
create table t_p
Hi Amit,
I have pulled latest sources from git and tried to create multi-level
partition, getting a server crash, below are steps to reproduce. please
check if it is reproducible in your machine also.
postgres=# CREATE TABLE test_ml (a int, b int, c varchar) PARTITION BY
RANGE(a);
CREATE TABLE
p
On 2016/12/26 19:46, Amit Langote wrote:
> (Perhaps, the following should be its own new thread)
>
> I noticed that ExecProcessReturning() doesn't work properly after tuple
> routing (example shows how returning tableoid currently fails but I
> mention some other issues below):
>
> create table p
Sorry about the delay in replying.
On 2016/12/23 8:08, Robert Haas wrote:
> On Thu, Dec 22, 2016 at 3:35 AM, Amit Langote
> wrote:
>> While working on that, I discovered yet-another-bug having to do with the
>> tuple descriptor that's used as we route a tuple down a partition tree. If
>> attnums
On Thu, Dec 22, 2016 at 3:35 AM, Amit Langote
wrote:
> While working on that, I discovered yet-another-bug having to do with the
> tuple descriptor that's used as we route a tuple down a partition tree. If
> attnums of given key attribute(s) are different on different levels, it
> would be incorre
On 2016/12/22 1:50, Robert Haas wrote:
> On Wed, Dec 21, 2016 at 5:33 AM, Amit Langote
> wrote:
>> Breaking changes into multiple commits/patches does not seem to work for
>> adding regression tests. So, I've combined multiple patches into a single
>> patch which is now patch 0002 in the attached
On Wed, Dec 21, 2016 at 5:33 AM, Amit Langote
wrote:
> Breaking changes into multiple commits/patches does not seem to work for
> adding regression tests. So, I've combined multiple patches into a single
> patch which is now patch 0002 in the attached set of patches.
Ugh, seriously? It's fine t
On 2016/12/21 1:53, Robert Haas wrote:
> On Mon, Dec 19, 2016 at 10:59 PM, Robert Haas wrote:
>> On Sun, Dec 18, 2016 at 10:00 PM, Amit Langote
>> wrote:
>>> Here are updated patches including the additional information.
>>
>> Thanks. Committed 0001. Will have to review the others when I'm less
On 2016/12/21 14:03, Amit Langote wrote:
> OK, updated patch attached.
Oops, incomplete patch that was. Complete patch attached this time.
Thanks,
Amit
diff --git a/src/backend/commands/tablecmds.c b/src/backend/commands/tablecmds.c
index 1c219b03dd..115b98313e 100644
--- a/src/backend/commands/
On 2016/12/21 13:42, Robert Haas wrote:
> On Tue, Dec 20, 2016 at 9:14 PM, Amit Langote
> wrote:
>> On 2016/12/21 1:45, Alvaro Herrera wrote:
>>> Robert Haas wrote:
On Tue, Dec 20, 2016 at 10:27 AM, Alvaro Herrera
wrote:
> Even if we decide to keep the message, I think it's not very
On Tue, Dec 20, 2016 at 9:14 PM, Amit Langote
wrote:
> On 2016/12/21 1:45, Alvaro Herrera wrote:
>> Robert Haas wrote:
>>> On Tue, Dec 20, 2016 at 10:27 AM, Alvaro Herrera
>>> wrote:
Even if we decide to keep the message, I think it's not very good
wording anyhow; as a translator I disl
On 2016/12/21 1:45, Alvaro Herrera wrote:
> Robert Haas wrote:
>> On Tue, Dec 20, 2016 at 10:27 AM, Alvaro Herrera
>> wrote:
>>> Even if we decide to keep the message, I think it's not very good
>>> wording anyhow; as a translator I disliked it on sight. Instead of
>>> "skipping scan to validate"
1 - 100 of 309 matches
Mail list logo
