Re: [HACKERS] Explicit relation name in VACUUM VERBOSE log

2017-08-21 Thread Simon Riggs
On 15 August 2017 at 02:27, Masahiko Sawada wrote: > Is there any reasons why we don't > write an explicit name in vacuum verbose logs? None. Sounds like a good idea. > If not, can we add > schema names to be more clearly? Yes, we can. I'm not sure why you would do this only for VACUUM though?

[HACKERS] locale problem of bgworker: logical replication launcher and worker process

2017-08-21 Thread Ioseph Kim
Hi, I tried ver. 10 beta3. I had below messages. - $ pg_ctl start 서버를 시작하기 위해 기다리는 중완료 서버 시작됨 2017-08-22 14:06:21.248 KST [32765] 로그: IPv6, 주소: "::1", 포트 5433 번으로 접속을 허용합니다 2017-08-22 14:06:21.248 KST [32765] 로그: IPv4, 주소: "127.0.0.1", 포트 5433 번으로 접속을 허용합니다 2017-08-22 14:06:21.364 KST

Re: [HACKERS] Re: ICU collation variant keywords and pg_collation entries (Was: [BUGS] Crash report for some ICU-52 (debian8) COLLATE and work_mem values)

2017-08-21 Thread Peter Geoghegan
On Mon, Aug 21, 2017 at 4:48 PM, Peter Eisentraut wrote: > On 8/21/17 12:33, Peter Geoghegan wrote: >> On Mon, Aug 21, 2017 at 8:23 AM, Peter Eisentraut >> wrote: >>> Here are my patches to address this. >> >> These look good. > > Committed. That closes this open item. Thanks again. -- Peter

Re: [HACKERS] A suspicious code in pgoutput_startup().

2017-08-21 Thread Yugo Nagata
On Tue, 15 Aug 2017 16:23:35 -0400 Peter Eisentraut wrote: > On 7/27/17 20:52, Yugo Nagata wrote: > > 175 /* Check if we support requested protocol */ > > 176 if (data->protocol_version != LOGICALREP_PROTO_VERSION_NUM) > > 177 ereport(ERROR, > > 178

Re: [HACKERS] A little improvementof ApplyLauncherMain loop code

2017-08-21 Thread Yugo Nagata
On Tue, 15 Aug 2017 15:17:06 -0400 Peter Eisentraut wrote: > On 8/1/17 02:28, Yugo Nagata wrote: > > When reading the logical replication code, I found that the following > > part could be improved a bit. In the foreach, LWLockAcquire and > > logicalrep_worker_find are called for each loop, but t

Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization

2017-08-21 Thread Masahiko Sawada
On Wed, Aug 16, 2017 at 4:55 PM, Fabien COELHO wrote: > > Hello Masahiko-san, > >> Yeah, once custom initialization patch get committed we can extend it. >> >> Attached updated patch. I've incorporated the all comments from Fabien >> to it, and changed it to single letter version. > > > Patch appl

Re: [HACKERS] Default Partition for Range

2017-08-21 Thread Jeevan Ladhe
Hi Beena, On Thu, Aug 17, 2017 at 4:59 PM, Beena Emerson wrote: > PFA the patch rebased over v25 patches of default list partition [1] > Thanks for rebasing. Range partition review: 1. There are lot of changes in RelationBuildPartitionDesc(). It was hard to understand why these changes are ne

Re: [HACKERS] Tuple-routing for certain partitioned tables not working as expected

2017-08-21 Thread Amit Langote
On 2017/08/22 1:08, Robert Haas wrote: > On Mon, Aug 21, 2017 at 7:45 AM, Etsuro Fujita > wrote: >> If there are no objections, I'll add this to the open item list for v10. > > This seems fairly ad-hoc to me. I mean, now you have > CheckValidResultRel not being called in just this one case -- bu

Re: [HACKERS] Setting pd_lower in GIN metapage

2017-08-21 Thread Amit Langote
On 2017/08/22 9:39, Michael Paquier wrote: > On Tue, Jun 27, 2017 at 4:56 PM, Amit Langote > wrote: >> On 2017/06/27 10:22, Michael Paquier wrote: >>> On Mon, Jun 26, 2017 at 4:11 PM, Masahiko Sawada >>> wrote: Thank you for the patches! I checked additional patches for brin and spgist

Re: [HACKERS] Setting pd_lower in GIN metapage

2017-08-21 Thread Michael Paquier
On Tue, Jun 27, 2017 at 4:56 PM, Amit Langote wrote: > On 2017/06/27 10:22, Michael Paquier wrote: >> On Mon, Jun 26, 2017 at 4:11 PM, Masahiko Sawada >> wrote: >>> Thank you for the patches! I checked additional patches for brin and >>> spgist. They look good to me. >> >> Last versions are stil

Re: [HACKERS] Patch: Add --no-comments to skip COMMENTs with pg_dump

2017-08-21 Thread David G. Johnston
On Mon, Aug 21, 2017 at 2:30 PM, Simon Riggs wrote: > > > The patch applies cleanly to current master and all tests run without > > failures. > > > > I also test against all current supported versions (9.2 ... 9.6) and > didn't > > find any issue. > > > > Changed status to "ready for commiter". >

Re: [HACKERS] Re: ICU collation variant keywords and pg_collation entries (Was: [BUGS] Crash report for some ICU-52 (debian8) COLLATE and work_mem values)

2017-08-21 Thread Peter Eisentraut
On 8/21/17 12:33, Peter Geoghegan wrote: > On Mon, Aug 21, 2017 at 8:23 AM, Peter Eisentraut > wrote: >> Here are my patches to address this. > > These look good. Committed. That closes this open item. > One small piece of feedback: I suggest naming the custom collation > "numeric" something e

Re: [HACKERS] [PATCH] Push limit to sort through a subquery

2017-08-21 Thread Michael Paquier
On Tue, Aug 22, 2017 at 3:43 AM, Robert Haas wrote: > Works for me. While I'm sure this won't eclipse previous achievements > in this area, it still seems worthwhile. This one is intentional per what happens in the US today? ;) -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers

Re: [HACKERS] Patch: Add --no-comments to skip COMMENTs with pg_dump

2017-08-21 Thread Simon Riggs
On 7 August 2017 at 16:14, Fabrízio de Royes Mello wrote: > > On Mon, Aug 7, 2017 at 10:43 AM, Robins Tharakan wrote: >> >> On 20 July 2017 at 05:14, Robins Tharakan wrote: >>> >>> On 20 July 2017 at 05:08, Michael Paquier >>> wrote: On Wed, Jul 19, 2017 at 8:59 PM, Fabrízio de R

Re: [HACKERS] Proposal : For Auto-Prewarm.

2017-08-21 Thread Robert Haas
On Mon, Aug 21, 2017 at 2:42 AM, Mithun Cy wrote: > Thanks for the patch, I have tested the above fix now it works as > described. From my test patch looks good, I did not find any other > issues. Considering the totality of the circumstances, it seemed appropriate to me to commit this. So I did

Re: [HACKERS] [PATCH] Push limit to sort through a subquery

2017-08-21 Thread Robert Haas
On Fri, Aug 18, 2017 at 4:08 PM, Douglas Doole wrote: >> 4. I am pretty doubtful that "Memory: 25kB" is going to be stable >> enough for us to want that output memorialized in the regression ... > > Fair enough. I wanted to be a bit more sophisticated in my check than > looking for a single value

Re: [HACKERS] Re: ICU collation variant keywords and pg_collation entries (Was: [BUGS] Crash report for some ICU-52 (debian8) COLLATE and work_mem values)

2017-08-21 Thread Peter Geoghegan
On Mon, Aug 21, 2017 at 9:33 AM, Peter Geoghegan wrote: > On Mon, Aug 21, 2017 at 8:23 AM, Peter Eisentraut > wrote: >> Here are my patches to address this. > > These look good. Also, I don't know why en-u-kr-others-digit wasn't accepted by CREATE COLLATION, as you said on the other thread just

Re: [HACKERS] Re: ICU collation variant keywords and pg_collation entries (Was: [BUGS] Crash report for some ICU-52 (debian8) COLLATE and work_mem values)

2017-08-21 Thread Peter Geoghegan
On Mon, Aug 21, 2017 at 8:23 AM, Peter Eisentraut wrote: > Here are my patches to address this. These look good. One small piece of feedback: I suggest naming the custom collation "numeric" something else instead: "natural". Apparently, the behavior it implements is sometimes called natural sort

Re: [HACKERS] Tuple-routing for certain partitioned tables not working as expected

2017-08-21 Thread Robert Haas
On Mon, Aug 21, 2017 at 7:45 AM, Etsuro Fujita wrote: > If there are no objections, I'll add this to the open item list for v10. This seems fairly ad-hoc to me. I mean, now you have CheckValidResultRel not being called in just this one case -- but that bypasses all the checks that function might

Re: [HACKERS] What users can do with custom ICU collations in Postgres 10

2017-08-21 Thread Peter Eisentraut
On 8/15/17 15:04, Peter Geoghegan wrote: > * "23.2.2.3. Copying Collations" suggests that the only use of CREATE > COLLATION is copying collations, which is far from true with ICU. We > should change that at the same time as this change is made. I think > that just changing the title would improve

Re: [HACKERS] Re: ICU collation variant keywords and pg_collation entries (Was: [BUGS] Crash report for some ICU-52 (debian8) COLLATE and work_mem values)

2017-08-21 Thread Peter Eisentraut
On 8/19/17 19:15, Peter Geoghegan wrote: > Noah Misch wrote: >> I think you're contending that, as formulated, this is not a valid v10 open >> item. Are you? > > As the person that came up with this formulation, I'd like to give a > quick summary of my current understanding of the item's status:

Re: [HACKERS] shm_mq_wait_internal gets stuck forever on fast shutdown

2017-08-21 Thread Robert Haas
On Mon, Aug 21, 2017 at 10:07 AM, Craig Ringer wrote: > Makes sense, and I'm not especially concerned. If the expected solution to > such usage is to use non-blocking calls, that's fine with me. > > I partly wanted to put this out there to help the next person looking into > it. Or myself, when I'

Re: [HACKERS] index-only count(*) for indexes supporting bitmap scans

2017-08-21 Thread Alexander Kumenkov
|Hello everyone, I made a new patch according to the previous comments. It is simpler now, only adding a few checks to the bitmap heap scan node. When the target list for the bitmap heap scan is empty, and there is no filter, and the bitmap page generated by the index scan is exact, and the c

Re: [HACKERS] shm_mq_wait_internal gets stuck forever on fast shutdown

2017-08-21 Thread Craig Ringer
On 21 August 2017 at 21:44, Robert Haas wrote: > While this would work, I don't really see the need for it given the > availability of nonblocking operations. See mq_putmessage() for an > example. > Makes sense, and I'm not especially concerned. If the expected solution to such usage is to use

Re: [HACKERS] shm_mq_wait_internal gets stuck forever on fast shutdown

2017-08-21 Thread Robert Haas
On Sun, Aug 20, 2017 at 10:57 PM, Craig Ringer wrote: > I've noticed a possible bug / design limitation where shm_mq_wait_internal > sleep in a latch wait forever, and the postmaster gets stuck waiting for the > bgworker the wait is running in to exit. > > This happens when the shm_mq does not hav

Re: [HACKERS] [PROPOSAL] Text search configuration extension

2017-08-21 Thread Arthur Zakirov
Hello, On Fri, Aug 18, 2017 at 03:30:38PM +0300, Aleksandr Parfenov wrote: > Hello hackers! > > I'm working on a new approach in text search configuration and want to > share my thought with community in order to get some feedback and maybe > some new ideas. > There are several cases, where the

Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256

2017-08-21 Thread Michael Paquier
On Tue, Jun 20, 2017 at 1:11 PM, Michael Paquier wrote: > With the tests directly in the patch, things are easy to run. WIth > PG10 stabilization work, of course I don't expect much feedback :) > But this set of patches looks like the direction we want to go so as > JDBC and libpq users can take a

Re: [HACKERS] Regressions failures with libxml2 on ArchLinux

2017-08-21 Thread Michael Paquier
On Mon, Aug 14, 2017 at 7:36 PM, Michael Paquier wrote: > Thanks for adding the details directly, downgrading the hard way is > what I am doing now using the past packages of libxml2 in Arch's > archives [1]. ArchLinux is a bit wrong in the fact of shipping a > package with a behavior change. Let'

Re: [HACKERS] Tuple-routing for certain partitioned tables not working as expected

2017-08-21 Thread Etsuro Fujita
On 2017/08/07 15:45, Etsuro Fujita wrote: On 2017/08/07 15:33, Amit Langote wrote: On 2017/08/07 15:22, Etsuro Fujita wrote: On 2017/08/07 13:11, Amit Langote wrote:> The patch looks good too. Although, looking at the following hunk: + Assert(partrel->rd_rel->relkind == RELKIND_RELATI

Re: [HACKERS] postgres_fdw bug in 9.6

2017-08-21 Thread Etsuro Fujita
On 2017/04/08 4:24, Robert Haas wrote: Looking at the code itself, I find the changes to joinpath.c rather alarming. I missed this mail. Sorry about that, Robert. +/* Save hashclauses for possible use by the FDW */ +if (extra->consider_foreignjoin && hashclauses) +extra->hash

Re: [HACKERS] why not parallel seq scan for slow functions

2017-08-21 Thread Amit Kapila
On Mon, Aug 21, 2017 at 3:15 PM, Simon Riggs wrote: > On 21 August 2017 at 10:08, Amit Kapila wrote: > >> Thoughts? > > This seems like a very basic problem for parallel queries. > > The problem seems to be that we are calculating the cost of the plan > rather than the speed of the plan. > > Clea

Re: [HACKERS] why not parallel seq scan for slow functions

2017-08-21 Thread Simon Riggs
On 21 August 2017 at 10:08, Amit Kapila wrote: > Thoughts? This seems like a very basic problem for parallel queries. The problem seems to be that we are calculating the cost of the plan rather than the speed of the plan. Clearly, a parallel task has a higher overall cost but a lower time to c

Re: [HACKERS] Pluggable storage

2017-08-21 Thread Amit Kapila
On Mon, Aug 21, 2017 at 12:58 PM, Haribabu Kommi wrote: > > On Sun, Aug 13, 2017 at 5:17 PM, Amit Kapila > wrote: >> >> >> Also, it is quite possible that some of the storage Am's don't even >> want to return bool as a parameter from HeapTupleSatisfies* API's. I >> guess what we need here is to

Re: [HACKERS] parallelize queries containing initplans

2017-08-21 Thread Amit Kapila
On Mon, Aug 21, 2017 at 1:44 PM, Haribabu Kommi wrote: > > > Thanks for adding more details. It is easy to understand. > > I marked the patch as ready for committer in the commitfest. > Thank you. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hacke

Re: [HACKERS] why not parallel seq scan for slow functions

2017-08-21 Thread Amit Kapila
On Wed, Aug 16, 2017 at 5:04 PM, Robert Haas wrote: > On Wed, Aug 16, 2017 at 7:23 AM, Amit Kapila wrote: >> On Tue, Aug 15, 2017 at 7:15 PM, Robert Haas wrote: >>> On Sat, Aug 12, 2017 at 9:18 AM, Amit Kapila >>> wrote: I think skipping a generation of gather paths for scan node or top >

Re: [HACKERS] parallelize queries containing initplans

2017-08-21 Thread Haribabu Kommi
On Mon, Aug 14, 2017 at 8:41 PM, Amit Kapila wrote: > On Sun, Aug 13, 2017 at 6:49 PM, Haribabu Kommi > wrote: > > On Fri, Aug 11, 2017 at 1:18 AM, Amit Kapila > > wrote: > >> > > > > Thanks for the updated patch. Patch looks fine. I just have some > > minor comments. > > > > + * ExecEvalParamE

Re: [HACKERS] assorted code cleanup

2017-08-21 Thread Michael Meskes
> And there are many "(0)" "S_ANYTHING" in src/interfaces/ecpg/test/ and > src/interfaces/ecpg/preproc/. I might have missed something here, but where/why is S_ANYTHING a problem? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Pos

[HACKERS] Document pgstattuple privileges without ambiguity

2017-08-21 Thread Feike Steenbergen
Hi, When installing pgstattuple on 10, the documentation about its privileges was unclear to me. (Does the pg_stat_scan_tables role get EXECUTE privileges by default or not?). By making the privilege paragraph less verbose and a duplicate of the paragraph used for pgfreespacemap and pgbuffercache

Re: [HACKERS] [RFC] What would be difficult to make data models pluggable for making PostgreSQL a multi-model database?

2017-08-21 Thread Chris Travers
On Sun, Aug 20, 2017 at 4:10 AM, MauMau wrote: > From: Chris Travers > > Why cannot you do all this in a language handler and treat as a user > defined function? > > ... > > If you have a language handler for cypher, why do you need in_region > or cast_region? Why not just have a graph_search()

Re: [HACKERS] expanding inheritance in partition bound order

2017-08-21 Thread Amit Langote
On 2017/08/21 13:11, Ashutosh Bapat wrote: > On Sat, Aug 19, 2017 at 1:21 AM, Robert Haas wrote: >> On Fri, Aug 18, 2017 at 1:17 AM, Ashutosh Bapat >> wrote: >>> 0004 patch in partition-wise join patchset has code to expand >>> partition hierarchy. That patch is expanding inheritance hierarchy in

Re: [HACKERS] Pluggable storage

2017-08-21 Thread Haribabu Kommi
On Sun, Aug 13, 2017 at 5:17 PM, Amit Kapila wrote: > On Sat, Aug 12, 2017 at 10:31 AM, Haribabu Kommi > wrote: > >> > >> Why do we need to store handler function in TupleDesc? As of now, the > >> above patch series has it available in RelationData and > >> TupleTableSlot, I am not sure if inst

[HACKERS] advanced partition matching algorithm for partition-wise join

2017-08-21 Thread Ashutosh Bapat
The patch-set in [1] supports partition-wise join when the partition bounds and partition keys of the joining tables exactly match. The last two patches in the last few patch-sets in that thread implement more advanced partition matching code. In order to avoid mixing reviews for advanced partition