Missing wal_receiver_status_interval in Subscribers section

Hi, I found that the doc says in 19.6.4. Subscribers section that "Note that wal_receiver_timeout and wal_retrieve_retry_interval configuration parameters affect the logical replication workers as well" but subscriber actually uses wal_receiver_status_interval as well. So I think we should

Re: [HACKERS] Proposal: Local indexes for partitioned table

On 15 November 2017 at 06:49, Alvaro Herrera wrote: > Here's the remaining bits, rebased. I wonder if it should be this patches job to alter the code in get_relation_info() which causes the indexes not to be loaded for partitioned tables: /* * Make list of indexes.

Re: pspg - psql pager

Il 15/11/17 10:41, Pavel Stehule ha scritto: > Hi > > I finished new pager, that can be interesting for postgresql expert users. > It is now on apt.postgresql.org http://postgr.es/m/e1efc37-0007rv...@atalia.postgresql.org And will be in Debian Unstable soon as it is in the NEW queue for

Re: [HACKERS] Proposal: Local indexes for partitioned table

On 15 November 2017 at 06:49, Alvaro Herrera wrote: > Here's the remaining bits, rebased. Hi, I've not had time for a thorough look at this, but on a quick scan I noticed that CompareIndexInfo() missed checking if the Index AM matches the AM of the partitioned index.

Re: [HACKERS] path toward faster partition pruning

On 17 November 2017 at 23:01, Amit Langote wrote: > Please find attached updated patch set. There are significant changes in > this version as described below, including the support for hash > partitioned tables. > Hi Amit, Thanks for making those changes and

RE: Speed up the removal of WAL files

From: Kyotaro HORIGUCHI [mailto:horiguchi.kyot...@lab.ntt.co.jp] > The orinal code recycles some of the to-be-removed files, but the patch > removes all the victims. This may impact on performance. Yes, I noticed it after submitting the patch and was wondering what to do. Thinking simply, I

Re: Typo in comment

(2017/11/17 4:18), Robert Haas wrote: On Thu, Nov 16, 2017 at 6:53 AM, Etsuro Fujita wrote: Here is a patch for fixing a comment typo: s/datum1/datums1/. Thanks, committed. Thank you. Best regards, Etsuro Fujita

Re: pspg - psql pager

Hi, [Removed my email address in the OP, which I am not using since 2010 ;) ] On Thu, 2017-11-16 at 17:13 -0600, Merlin Moncure wrote: > This would be great package for inclusion in pgdg packaging as well. I released this package on Sep 15th, but just noticed the latest version. Pavel usually

Re: [HACKERS] Proposal: generic WAL compression

I wonder if the algorithm could be changed to operate with units of 2 or 4 bytes (instead of 1). Since the algorithm speed is essentially doubled/quadrupled it could yield a better runtime/compression trade-off. Does that make sense? -- Arthur Silva On Wed, Nov 1, 2017 at 12:43 AM, Oleg Ivanov

Re: [HACKERS] parallelize queries containing initplans

On Thu, Nov 16, 2017 at 10:44 PM, Robert Haas wrote: > On Thu, Nov 16, 2017 at 5:23 AM, Kuntal Ghosh > wrote: >> I've tested the above-mentioned scenario with this patch and it is >> working fine. Also, I've created a text column named

Re: [HACKERS] Partition-wise aggregation/grouping

On Wed, Nov 15, 2017 at 5:31 PM, Jeevan Chalke wrote: > > OK. Done in the attached patch set. > > I have rebased all my patches on latest HEAD which is at > 7518049980be1d90264addab003476ae105f70d4 > > Thanks These are review comments for the last set and I think

Re: [HACKERS] [PATCH] A hook for session start

On Fri, Nov 17, 2017 at 3:33 AM, Ashutosh Sharma wrote: > > On Fri, Nov 17, 2017 at 9:08 AM, Fabrízio de Royes Mello > wrote: > > Hi all, > > > > Attached new version of the patch fixing issues about installcheck and some > > assertions reported

Sv: Re: pspg - psql pager

På fredag 17. november 2017 kl. 10:09:53, skrev Marco Nenciarini < marco.nenciar...@2ndquadrant.it >: Il 15/11/17 10:41, Pavel Stehule ha scritto: > Hi > > I finished new pager, that can be interesting for postgresql expert users. > It is now on

Re: [HACKERS] Transaction control in procedures

On 11/16/17 18:35, Simon Riggs wrote: > For the first two answers above the answer was "currently executing > statement", yet the third answer seems to be the procedure. So that is > a slight discrepancy. That's the way function execution, or really any nested execution, currently works. > ISTM

Re: Repetitive code in RI triggers

The following review has been posted through the commitfest application: make installcheck-world: tested, failed Implements feature: tested, failed Spec compliant: tested, failed Documentation:tested, failed The patch looks good. It just removes repetitive code and I

Re: Treating work_mem as a shared resource (Was: Parallel Hash take II)

On Thu, Nov 16, 2017 at 11:50 AM, Serge Rielau wrote: > Just as you have, we have also considered holistic provisioning of > work_mem across all consumers, but we find that to be too complex. > Having an “emergency fund” in shared memory is also an option, but I find > it too

Re: Repetitive code in RI triggers

On Fri, 17 Nov 2017 15:05:31 + Ildus Kurbangaliev wrote: > The following review has been posted through the commitfest > application: make installcheck-world: tested, failed > Implements feature: tested, failed > Spec compliant: tested, failed >

PG10.1 autovac killed building extended stats

After adding extended/MV stats to a few of our tables a few days ago, it looks like I wasn't been paying attention and this first crashed 2 nights ago. Why at 1am? not sure. I have an "reindex" job which runs at 1am, and an vacuum/analyze job which runs at 2am, but I don't use cron to change

feature request: consume asynchronous notification via a function

Hackers, Currently the only way that I know of to consume async notifications via SQL (as opposed to a client application) is via dblink_get_notify. This method isn't very good; it requires some extra support coding, eats a connection and a backend, and doesn't have any timeout facilities. The

Re: Inlining functions with "expensive" parameters

On Thu, Nov 16, 2017 at 12:37 PM, Andres Freund wrote: > Hi, > > On 2017-11-16 15:27:59 -0500, Tom Lane wrote: > > Andres Freund writes: > > > On November 16, 2017 11:44:52 AM PST, Tom Lane > wrote: > > >> Yeah, there's no mechanism

Re: [HACKERS] SERIALIZABLE on standby servers

On Thu, Nov 16, 2017 at 5:52 PM, Simon Riggs wrote: >> I haven't looked at this again yet but a nearby thread reminded me of >> another problem with this which I wanted to restate explicitly here in >> the context of this patch. Even without replication in the picture, >>

Re: Inlining functions with "expensive" parameters

On November 17, 2017 5:15:57 AM PST, Paul Ramsey wrote: >On Thu, Nov 16, 2017 at 12:37 PM, Andres Freund >wrote: > >> Hi, >> >> On 2017-11-16 15:27:59 -0500, Tom Lane wrote: >> > Andres Freund writes: >> > > On November 16,

Re: [COMMITTERS] pgsql: Add hash partitioning.

On Thu, Nov 16, 2017 at 9:37 AM, amul sul wrote: > Fixed in the 001 patch. > > IMHO, this function is not meant for a user, so that instead of ereport() cant > we simply return false? TWIW, I have attached 003 patch which replaces all > erepots() by return false. I don't

Re: bgwriter_lru_maxpages range in postgresql.conf

On Thu, Nov 16, 2017 at 4:40 PM, Jeff Janes wrote: > I changed it to "0 disables" to be more consistent with other locations. Committed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: Speed up the removal of WAL files

On Fri, Nov 17, 2017 at 5:20 PM, Tsunakawa, Takayuki wrote: > From: Kyotaro HORIGUCHI [mailto:horiguchi.kyot...@lab.ntt.co.jp] >> The orinal code recycles some of the to-be-removed files, but the patch >> removes all the victims. This may impact on performance. >

Re: Treating work_mem as a shared resource (Was: Parallel Hash take II)

On Fri, Nov 17, 2017 at 3:31 PM, Robert Haas wrote: > On Thu, Nov 16, 2017 at 11:50 AM, Serge Rielau wrote: > >> Just as you have, we have also considered holistic provisioning of >> work_mem across all consumers, but we find that to be too complex. >>

Re: PG10.1 autovac crashed building extended stats

On Fri, Nov 17, 2017 at 01:27:49PM -0300, Alvaro Herrera wrote: > Justin Pryzby wrote: > > After adding extended/MV stats to a few of our tables a few days ago, it > > looks > > like I wasn't been paying attention and this first crashed 2 nights ago. > > Why > > at 1am? not sure. I have an

Re: Fix number skipping in to_number

I wrote: > That leads me to the attached patch. There is more that could be done > here --- in particular, I'd like to see the character-not-byte-count > rule extended to literal text. But that seems like fit material for > a different patch. Hearing no further comments, I pushed that patch.

Re: Treating work_mem as a shared resource (Was: Parallel Hash take II)

On Fri, Nov 17, 2017 at 7:31 AM, Robert Haas wrote: > On Thu, Nov 16, 2017 at 11:50 AM, Serge Rielau wrote: >> >> Just as you have, we have also considered holistic provisioning of work_mem >> across all consumers, but we find that to be too complex. >>

Re: [HACKERS] Consistently catch errors from Python _New() functions

Peter Eisentraut writes: > While reviewing some unrelated code, I noticed that we are handling > error conditions from Python API functions such as PyList_New() and > PyDict_New() in pretty random ways or not at all. Here is a patch to > fix that. This needs

Re: PG10.1 autovac killed building extended stats

Justin Pryzby wrote: > After adding extended/MV stats to a few of our tables a few days ago, it looks > like I wasn't been paying attention and this first crashed 2 nights ago. Why > at 1am? not sure. I have an "reindex" job which runs at 1am, and an > vacuum/analyze job which runs at 2am, but

Re: PG10.1 autovac killed building extended stats

Justin Pryzby wrote: > Core was generated by `postgres: autovacuum worker process gtt > '. > Program terminated with signal 11, Segmentation fault. > #0 statext_ndistinct_build (totalrows=300, numrows=300, rows=0x21df3e8, > attrs=, stats=0x0) at mvdistinct.c:103 > 103

Re: [HACKERS] Parallel Hash take II

Hi, On 2017-11-14 01:30:30 +1300, Thomas Munro wrote: > New patch attached. (I've commit some of the preliminary work) Looking at 0005-Add-infrastructure-for-sharing-temporary-files-betwe.patch: - The created path/filenames seem really redundant:

Re: pspg - psql pager

2017-11-15 10:41 GMT+01:00 Pavel Stehule : > Hi > > I finished new pager, that can be interesting for postgresql expert users. > > It demonstrate some possibilities of TUI and I hope it shows some possible > directions of future possibilities of psql. > > It is available

Re: PG10.1 autovac killed building extended stats

On Fri, Nov 17, 2017 at 01:36:00PM -0300, Alvaro Herrera wrote: > Justin Pryzby wrote: > > > Core was generated by `postgres: autovacuum worker process gtt > > '. > > Program terminated with signal 11, Segmentation fault. > > #0 statext_ndistinct_build (totalrows=300, numrows=300,

Re: Treating work_mem as a shared resource (Was: Parallel Hash take II)

On Fri, Nov 17, 2017 at 12:48 PM, Tom Lane wrote: >> I'd like to hear some opinions on the feasibility of this approach. > > There is indeed a big planning problem here, but Robert's sketch is > missing an important component of it: work_mem is not an output of cost >

Re: no library dependency in Makefile?

I very much look forward to hearing everyone's views on this issue. If the solution mentioned before is ok, I will start to complete it. thanks 高增琦 于2017年11月16日 周四20:51写道： > LDFLAGS in the example changed to: > > ''' > override LDFLAGS := $(call expand_stlibs,$(STLIBS))

Re: [HACKERS] Parallel Hash take II

On Thu, Nov 16, 2017 at 6:42 PM, Andres Freund wrote: > What I'm basically worried about is that the *only* reason for some > plans to choose to use parallelism is that essentially the effective > amount of work_mem between the plans is that the parallel one uses >

Re: Treating work_mem as a shared resource (Was: Parallel Hash take II)

On Fri, Nov 17, 2017 at 3:23 PM, Robert Haas wrote: > Hmm. I wonder if you are correct that hashing is the special case. > Hashing and sorting are of course the two main operations -- but > there's materialize and anything else that uses a CTE, and maybe other > stuff I'm

Re: [HACKERS] Parallel Hash take II

On Fri, Nov 17, 2017 at 1:55 PM, Andres Freund wrote: > Looking at 0005-Add-infrastructure-for-sharing-temporary-files-betwe.patch: > - The created path/filenames seem really redundant: > base/pgsql_tmp/pgsql_tmp11160.9.sharedfileset.d/pgsql_tmp.o3of8.p0.0 > > Including

Re: Treating work_mem as a shared resource (Was: Parallel Hash take II)

On Fri, Nov 17, 2017 at 1:22 PM, Peter Geoghegan wrote: > Right. The ability for sorts to do well with less memory is really > striking these days. And though I didn't mean to seriously suggest it, > a hash_mem GUC does seem like it solves some significant problems > without much

Re: [HACKERS] Parallel Hash take II

Hi, On 2017-11-14 01:30:30 +1300, Thomas Munro wrote: > New patch attached. 0002-Add-a-barrier-primitive-for-synchronizing-backends.patch - Intro starts with: + * + * This implementation of barriers allows for static sets of participants + * known up front, or dynamic sets of participants which

Re: default range partition and constraint exclusion

On Fri, Nov 17, 2017 at 12:57 AM, Amit Langote wrote: > While working on the patch for partition pruning for declarative > partitioned tables, I noticed that default range partition will fail to be > included in a plan in certain cases due to pruning by constraint

Re: Fix number skipping in to_number

I wrote: > That leads me to the attached patch. There is more that could be done > here --- in particular, I'd like to see the character-not-byte-count > rule extended to literal text. But that seems like fit material for > a different patch. Attached is a patch that makes formatting.c more

Re: [HACKERS] pg_upgrade to clusters with a different WAL segment size

On Mon, Nov 13, 2017 at 3:09 PM, Tom Lane wrote: >> On Tue, Nov 14, 2017 at 7:32 AM, Andres Freund wrote: >>> Even if that's the case, I fail to see why it'd be a good idea to have >>> any sort of pg_upgrade integration here. We should make pg_resetwal's