Re: [HACKERS] Small patch for pg_basebackup argument parsing

Hi Pierre, I tried to apply your patch to test it (though reading Robert's last comment it seems we wish to have it adjusted before committing)... but in any case I was not able to apply your patch to the tip of the master branch (my git apply failed). I'm setting this to Waiting On Author

Re: [HACKERS] CommitFest 2017-09 - How do I know what commit to apply patches to

Hello Ryan, I was diving into CommitFest 2017-09 to help review some patches, Thanks! but I was not sure which version / git commit / git tag of the PostgreSQL repo I should be checked out to in order to correctly apply / test these patches. Is

Re: [HACKERS] CommitFest 2017-09 - How do I know what commit to apply patches to

On Wed, Jul 5, 2017 at 5:42 PM, Ryan Murphy wrote: > Hello PostgreSQL hackers, > > I was diving into CommitFest 2017-09 to help review some patches, but I was > not sure which version / git commit / git tag of the PostgreSQL repo I > should be checked out to in order to

[HACKERS] CommitFest 2017-09 - How do I know what commit to apply patches to

Hello PostgreSQL hackers, I was diving into CommitFest 2017-09 to help review some patches, but I was not sure which version / git commit / git tag of the PostgreSQL repo I should be checked out to in order to correctly apply / test these patches. Is there

Re: [HACKERS] Incorrect mentions to pg_xlog in walmethods.c/h

On Wed, Jul 5, 2017 at 2:29 PM, Ryan Murphy wrote: > The following review has been posted through the commitfest application: > make installcheck-world: not tested > Implements feature: not tested > Spec compliant: not tested > Documentation:not

Re: [HACKERS] Incorrect mentions to pg_xlog in walmethods.c/h

The following review has been posted through the commitfest application: make installcheck-world: not tested Implements feature: not tested Spec compliant: not tested Documentation:not tested This commit only affects comments, so I'm confident it doesn't break code,

Re: [HACKERS] pgsql 10: hash indexes testing

On Wed, Jul 5, 2017 at 9:53 AM, AP wrote: > On Wed, Jul 05, 2017 at 08:10:10AM +0530, Amit Kapila wrote: >> On Tue, Jul 4, 2017 at 4:27 PM, AP wrote: >> > There is one index that caused an issue. Towards the end of an import >> > I got the following error: >> >

Re: [HACKERS] pgsql 10: hash indexes testing

On Wed, Jul 05, 2017 at 08:10:10AM +0530, Amit Kapila wrote: > On Tue, Jul 4, 2017 at 4:27 PM, AP wrote: > > There is one index that caused an issue. Towards the end of an import > > I got the following error: > > > > out of overflow pages in hash index > > > > The data being

Re: [HACKERS] Request more documentation for incompatibility of parallelism and plpgsql exec_run_select

> On Jul 3, 2017, at 10:25 PM, Amit Kapila wrote: > > On Mon, Jul 3, 2017 at 8:57 PM, Simon Riggs wrote: >> On 30 June 2017 at 05:14, Amit Kapila wrote: >> >>> This is explained in section 15.2 [1], refer below para:

Re: [HACKERS] Error while copying a large file in pg_rewind

On Tue, Jul 4, 2017 at 4:41 PM, Kuntal Ghosh wrote: > I've not yet started the patch and it may take some time for me to > understand and write > the patch in a correct way. Since, you've almost written the patch, > IMHO, please go ahead > and submit the patch. I'll

Re: [HACKERS] pgsql 10: hash indexes testing

On Tue, Jul 4, 2017 at 3:57 AM, AP wrote: > > The data being indexed is BYTEA, (quasi)random and 64 bytes in size. > The table has over 2 billion entries. The data is not unique. There's > an average of 10 duplicates for every unique value. > What is the number of duplicates

Re: [HACKERS] pgsql 10: hash indexes testing

On Tue, Jul 4, 2017 at 4:27 PM, AP wrote: > Hi, > > As I am actively working on a big project I figured I'd give PGSQL 10 a > go, primarily because of hash indexes. > > PostgreSQL 10 version in use is: > 10~beta2~20170620.2224-1~491.gitd412f79.pgdg+1 > > Things are mostly well

Re: [HACKERS] Reducing runtime of stats regression test

On Wed, May 03, 2017 at 11:43:43PM -0400, Tom Lane wrote: > On a reasonably fast development machine, one of the biggest time sinks > while running the core regression tests is the long "sleep" calls in the > stats.sql regression test. I took a closer look at these, and I think > we could

[HACKERS] Unused variable scanned_tuples in LVRelStats

Hi, scanned_tuples variable in LVRelStats is introduced by commit b4b6923e but it seems to me that it's actually not used. We store num_tuples into vacrelstats->scanned_tuples after scanned all blocks, and the comment mentioned that saving it in order to use later but we actually use num_tuples

Re: [HACKERS] pg_stop_backup(wait_for_archive := true) on standby server

On Sun, Jul 2, 2017 at 4:39 PM, Michael Paquier wrote: > On Sat, Jul 1, 2017 at 3:59 AM, Stephen Frost wrote: >> * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: >>> On 6/30/17 04:08, Masahiko Sawada wrote: >>> >> I'm not sure. I think

Re: [HACKERS] Add support for tuple routing to foreign partitions

Fujita-san, On 2017/06/29 20:20, Etsuro Fujita wrote: > Hi, > > Here is a patch for $subject. This is based on Amit's original patch > (patch '0007-Tuple-routing-for-partitioned-tables-15.patch' in [1]). Thanks a lot for taking this up. > Main changes are: > > * I like Amit's idea that for

[HACKERS] pgsql 10: hash indexes testing

Hi, As I am actively working on a big project I figured I'd give PGSQL 10 a go, primarily because of hash indexes. PostgreSQL 10 version in use is: 10~beta2~20170620.2224-1~491.gitd412f79.pgdg+1 Things are mostly well with hash indexes (plain, non-unique) giving me a rather lovely saving in

[HACKERS] GSoC 2017: weekly progress reports (week 5) and Proposal for predicate locking in gin index

Project: Explicitly support predicate locks in index AMs besides b-tree Hi, During this week, I read documentation and source code of gin index to find appropriate places to insert calls to existing functions. Proposal Gin index consists of a Btree index over key values, where each key is an

Re: [HACKERS] WIP patch: distinguish selectivity of < from <= and > from >=

On Tue, Jul 4, 2017 at 10:56 PM, Kuntal Ghosh wrote: > On Tue, Jul 4, 2017 at 9:20 PM, Tom Lane wrote: >> Kuntal Ghosh writes: >>> On Tue, Jul 4, 2017 at 9:23 AM, Tom Lane wrote: ... I have to

Re: [HACKERS] WIP patch: distinguish selectivity of < from <= and > from >=

On Tue, Jul 4, 2017 at 9:20 PM, Tom Lane wrote: > Kuntal Ghosh writes: >> On Tue, Jul 4, 2017 at 9:23 AM, Tom Lane wrote: >>> ... I have to admit that I've failed to wrap my brain around exactly >>> why it's correct. The

Re: [HACKERS] WIP patch: distinguish selectivity of < from <= and > from >=

I wrote: > No, the thing that is bothering me is why it seems to be correct to > apply a positive correction for ">=", a negative correction for "<", > and no correction for "<=" or ">". That seems weird and I can't > construct a plausible explanation for it. After further thought, I can put a

Re: [HACKERS] WIP patch: distinguish selectivity of < from <= and > from >=

Kuntal Ghosh writes: > On Tue, Jul 4, 2017 at 9:23 AM, Tom Lane wrote: >> ... I have to admit that I've failed to wrap my brain around exactly >> why it's correct. The arguments that I've constructed so far seem to >> point in the direction of

Re: [HACKERS] WIP patch: distinguish selectivity of < from <= and > from >=

On Tue, Jul 4, 2017 at 9:23 AM, Tom Lane wrote: > Aside from the mind-bendingly-tedious changes in pg_operator.h, the meat > of the patch is in selfuncs.c's ineq_histogram_selectivity(), which now > applies a correction for equal values in the cases where we were getting > it

Re: [HACKERS] WIP patch: distinguish selectivity of < from <= and > from >=

Ashutosh Bapat writes: > On Tue, Jul 4, 2017 at 9:23 AM, Tom Lane wrote: >> regression=# explain analyze select * from tenk1 where thousand < 10; >> before: >> Bitmap Heap Scan on tenk1 (cost=5.14..241.38 rows=110 width=244) (actual >>

Re: [HACKERS] Default Partition for Range

Hello Beena, Thanks for the updated patch. It passes the basic tests which I performed. Few comments: 1. In check_new_partition_bound(), > /* Default case is not handled here */ >if (spec->is_default) >break; The default partition check here can be

Re: [HACKERS] UPDATE of partition key

On 4 July 2017 at 14:48, Amit Khandekar wrote: > On 4 July 2017 at 14:38, Amit Langote wrote: >> On 2017/07/04 17:25, Etsuro Fujita wrote: >>> On 2017/07/03 18:54, Amit Langote wrote: On 2017/07/02 20:10, Robert Haas wrote: > That

Re: [HACKERS] WIP patch: distinguish selectivity of < from <= and > from >=

On Tue, Jul 4, 2017 at 9:23 AM, Tom Lane wrote: > > regression=# explain analyze select * from tenk1 where thousand < 10; > before: > Bitmap Heap Scan on tenk1 (cost=5.14..241.38 rows=110 width=244) (actual > time=0.121..0.623 rows=100 loops=1) > with patch: > Bitmap Heap

Re: [HACKERS] hash index on unlogged tables doesn't behave as expected

On Tue, Jul 4, 2017 at 1:23 PM, Michael Paquier wrote: > On Mon, Jul 3, 2017 at 7:40 PM, Amit Kapila wrote: > > It seems to me that this qualifies as an open item for 10. WAL-logging > is new for hash tables. Amit, could you add one? > Added.

Re: [HACKERS] UPDATE of partition key

On 4 July 2017 at 14:38, Amit Langote wrote: > On 2017/07/04 17:25, Etsuro Fujita wrote: >> On 2017/07/03 18:54, Amit Langote wrote: >>> On 2017/07/02 20:10, Robert Haas wrote: That seems pretty easy to do - just have expand_inherited_rtentry() notice

Re: [HACKERS] Update comment in ExecPartitionCheck

On 2017/07/04 17:55, Etsuro Fujita wrote: > This comment in an error handling in ExecPartitionCheck(): > > if (!ExecCheck(resultRelInfo->ri_PartitionCheckExpr, econtext)) > { > char *val_desc; > Relationorig_rel = rel; > > /* See the comment above. */ >

Re: [HACKERS] UPDATE of partition key

On 2017/07/04 17:25, Etsuro Fujita wrote: > On 2017/07/03 18:54, Amit Langote wrote: >> On 2017/07/02 20:10, Robert Haas wrote: >>> That >>> seems pretty easy to do - just have expand_inherited_rtentry() notice >>> that it's got a partitioned table and call >>> RelationGetPartitionDispatchInfo()

[HACKERS] Update comment in ExecPartitionCheck

This comment in an error handling in ExecPartitionCheck(): if (!ExecCheck(resultRelInfo->ri_PartitionCheckExpr, econtext)) { char *val_desc; Relationorig_rel = rel; /* See the comment above. */ if (resultRelInfo->ri_PartitionRoot) should be

Re: [HACKERS] UPDATE of partition key

On 2017/07/03 18:54, Amit Langote wrote: On 2017/07/02 20:10, Robert Haas wrote: But that seems like it wouldn't be too hard to fix: let's have expand_inherited_rtentry() expand the partitioned table in the same order that will be used by ExecSetupPartitionTupleRouting(). That's really what

Re: [HACKERS] hash index on unlogged tables doesn't behave as expected

On Mon, Jul 3, 2017 at 7:40 PM, Amit Kapila wrote: > There is already such a test, see create_index.sql. > CREATE UNLOGGED TABLE unlogged_hash_table (id int4); > CREATE INDEX unlogged_hash_index ON unlogged_hash_table USING hash (id > int4_ops); > > Do you have something

Re: [HACKERS] Multi column range partition table

On 3 July 2017 at 10:32, Amit Langote wrote: > On 2017/07/03 17:36, Dean Rasheed wrote: >> The bigger question is do we want this for PG10? If so, time is >> getting tight. My feeling is that we do, because otherwise we'd be >> changing the syntax in PG11 of a

Re: [HACKERS] Error while copying a large file in pg_rewind

On Tue, Jul 4, 2017 at 12:44 PM, Michael Paquier wrote: > On Tue, Jul 4, 2017 at 3:25 PM, Kuntal Ghosh > wrote: >> On Mon, Jul 3, 2017 at 6:50 PM, Michael Paquier >> wrote: >>> pg_basebackup/ with fe_recvint64()

Re: [HACKERS] Error while copying a large file in pg_rewind

On Tue, Jul 4, 2017 at 3:25 PM, Kuntal Ghosh wrote: > On Mon, Jul 3, 2017 at 6:50 PM, Michael Paquier > wrote: >> pg_basebackup/ with fe_recvint64() has its own way to do things, as >> does the large object things in libpq. I would think

Re: [HACKERS] Error while copying a large file in pg_rewind

On Mon, Jul 3, 2017 at 6:50 PM, Michael Paquier wrote: > pg_basebackup/ with fe_recvint64() has its own way to do things, as > does the large object things in libpq. I would think that at least on > HEAD things could be gathered with a small set of routines. It is >

Re: [HACKERS] Error while copying a large file in pg_rewind

On Tue, Jul 4, 2017 at 4:12 AM, Michael Paquier wrote: > On Tue, Jul 4, 2017 at 4:27 AM, Tom Lane wrote: >> Peter Eisentraut writes: >>> On 7/3/17 09:53, Tom Lane wrote: Hm. Before we add a bunch of code to