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 2017/04/14 5:28, Robert Haas wrote:
> On Thu, Apr 6, 2017 at 3:14 AM, Amit Langote
> wrote:
>>> The bulk of operations that work on traditional tables also work on
>>> partitions
>>> and partitioned tables. The next closest kind of relation, a materialized
>>> view, is far less table-like. T
On Thu, Apr 6, 2017 at 3:14 AM, Amit Langote
wrote:
>> The bulk of operations that work on traditional tables also work on
>> partitions
>> and partitioned tables. The next closest kind of relation, a materialized
>> view, is far less table-like. Therefore, I recommend showing both partitions
>
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
On 2017/04/06 16:02, Noah Misch wrote:
> On Wed, Jan 25, 2017 at 01:19:00PM -0500, Robert Haas wrote:
>> On Wed, Jan 25, 2017 at 1:04 PM, Peter Eisentraut
>> wrote:
>>> On 1/18/17 2:32 PM, Robert Haas wrote:
Unless we can find something official, I suppose we should just
display BASE TAB
On Wed, Jan 25, 2017 at 01:19:00PM -0500, Robert Haas wrote:
> On Wed, Jan 25, 2017 at 1:04 PM, Peter Eisentraut
> wrote:
> > On 1/18/17 2:32 PM, Robert Haas wrote:
> >> Unless we can find something official, I suppose we should just
> >> display BASE TABLE in that case as we do in other cases. I
On 2017/01/26 3:19, Robert Haas wrote:
> On Wed, Jan 25, 2017 at 1:04 PM, Peter Eisentraut
> wrote:
>> On 1/18/17 2:32 PM, Robert Haas wrote:
>>> Unless we can find something official, I suppose we should just
>>> display BASE TABLE in that case as we do in other cases. I wonder if
>>> the schema
On Fri, Mar 24, 2017 at 11:06 PM, Simon Riggs wrote:
> On 1 March 2017 at 01:36, Amit Langote wrote:
>
>> I don't know which way you're thinking of fixing this, but a planner patch
>> to implement faster partition-pruning will have taken care of this, I
>> think. As you may know, even declarativ
Hi Simon,
> > I don't know which way you're thinking of fixing this, but a planner patch
> > to implement faster partition-pruning will have taken care of this, I
> > think. As you may know, even declarative partitioned tables currently
> > depend on constraint exclusion for partition-pruning and
On 1 March 2017 at 01:36, Amit Langote wrote:
> I don't know which way you're thinking of fixing this, but a planner patch
> to implement faster partition-pruning will have taken care of this, I
> think. As you may know, even declarative partitioned tables currently
> depend on constraint exclus
Hi Tels,
Thanks a lot for the review!
> "corresponding"
Fixed.
> Also a question: Some one-line comments are
>
> /* Comment. */
>
> while others are
>
> /*
> * Comment.
> */
>
> Why the difference?
I'm trying to follow a code stile used in a code I'm modifying. In this
case I got an
Hi Aleksander,
noticed this in your patch:
> * Add a corespinding entry to pgStatTabHash.
"corresponding"
Also a question: Some one-line comments are
/* Comment. */
while others are
/*
* Comment.
*/
Why the difference?
Hope this helps,
Tels
PS: Sorry if this appears twice, I fumble
Hi Aleksander,
noticed this in your patch:
> * Add a corespinding entry to pgStatTabHash.
"corresponding"
Also a question: Some one-line comments are
/* Comment. */
while others are
/*
* Comment.
*/
Why the difference?
Hope this helps,
Tels
--
Sent via pgsql-hackers mailing list
Hi Amit,
> Sorry, I didn't mean to dissuade you from trying those
> micro-optimizations. If general inheritance cases can benefit from it
> (which, until we have a different method, will be used by partitioned
> tables as well), I think we should try it.
OK, I'll see what could be done here as w
Hi, Andres
Thanks a lot for the review!
> Why are we keeping that list / the "batch" allocation pattern? It
> doesn't actually seem useful to me after these changes. Given that we
> don't shrink hash-tables, we could just use the hash-table memory for
> this, no?
I don't think we can do that. A
Hi Aleksander,
On 2017/03/07 0:22, Aleksander Alekseev wrote:
> Hello.
>
> OK, here is a patch.
>
> Benchmark, before:
>
> ```
> number of transactions actually processed: 1823
> latency average = 1153.495 ms
> latency stddev = 154.366 ms
> tps = 6.061104 (including connections establishing)
>
Hi,
This issue has bothered me in non-partitioned use-cases recently, so
thanks for taking it up.
On 2017-03-06 18:22:17 +0300, Aleksander Alekseev wrote:
> diff --git a/src/backend/postmaster/pgstat.c b/src/backend/postmaster/pgstat.c
> index 2fb9a8bf58..fa906e7930 100644
> --- a/src/backend/po
Hello.
OK, here is a patch.
Benchmark, before:
```
number of transactions actually processed: 1823
latency average = 1153.495 ms
latency stddev = 154.366 ms
tps = 6.061104 (including connections establishing)
tps = 6.061211 (excluding connections establishing)
```
Benchmark, after:
```
number
Hi,
On 2017/02/28 23:25, Aleksander Alekseev wrote:
> Hello.
>
> I decided to figure out whether current implementation of declarative
> partitioning has any bottlenecks when there is a lot of partitions. Here
> is what I did [1].
Thanks for sharing.
> Then:
>
> ```
> # 2580 is some pk that ex
Hello.
I decided to figure out whether current implementation of declarative
partitioning has any bottlenecks when there is a lot of partitions. Here
is what I did [1].
```
-- init schema
\timing on
CREATE TABLE part_test (pk int not null, k int, v varchar(128)) PARTITION BY
RANGE(pk);
do $$
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
On Wed, Jan 25, 2017 at 1:04 PM, Peter Eisentraut
wrote:
> On 1/18/17 2:32 PM, Robert Haas wrote:
>> Unless we can find something official, I suppose we should just
>> display BASE TABLE in that case as we do in other cases. I wonder if
>> the schema needs some broader revision; for example, are
On 1/18/17 2:32 PM, Robert Haas wrote:
> Unless we can find something official, I suppose we should just
> display BASE TABLE in that case as we do in other cases. I wonder if
> the schema needs some broader revision; for example, are there
> information_schema elements intended to show informatio
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 Mon, Jan 23, 2017 at 5:25 AM, Amit Langote
wrote:
> I tried implementing the second idea in the attached patch. It fixes the
> bug (multiple reports as mentioned in the commit message) that tuples may
> be inserted into the wrong partition.
Looks good to me, thanks. Committed with a few twea
On 2017/01/19 5:25, Robert Haas wrote:
> On Wed, Jan 11, 2017 at 10:53 PM, Amit Langote wrote:
>> On 2017/01/06 20:23, Amit Langote wrote:
>>>
>>> If a single BulkInsertState object is passed to
>>> heap_insert()/heap_multi_insert() for different heaps corresponding to
>>> different partitions (fro
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 Wed, Jan 11, 2017 at 10:53 PM, Amit Langote
wrote:
> 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 y
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 Tue, Jan 10, 2017 at 4:17 AM, Amit Langote
wrote:
> 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 chang
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
1 - 100 of 536 matches
Mail list logo
