Re: [HACKERS] Re: proposal - using names as primary names of plpgsql function parameters instead $ based names

2017-09-11 22:28 GMT+02:00 Tom Lane : > Jeevan Chalke writes: > [ psql-named-arguments-03-jeevan.patch ] > > Pushed with minor simplification of the test case. > > I'm not quite as convinced as Pavel that this is an improvement --- > it will

Re: [HACKERS] pg_stat_wal_write statistics view

On Tue, Sep 12, 2017 at 2:04 AM, Kuntal Ghosh wrote: > On Wed, Sep 6, 2017 at 9:16 AM, Haribabu Kommi > wrote: > > > > Attached the latest patch and performance report. > > > While looking into the patch, I realized that a normal backend has

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

On Mon, Sep 11, 2017 at 11:43 PM, Robert Haas wrote: > So I think this is just an excuse for turning --no-security-labels > into --no-object-property=security-label. To me, that's just plain > worse. It does not seem that my thoughts here have been correctly transmitted

Re: [HACKERS] PG 10 release notes

On Tue, Aug 1, 2017 at 08:53:51AM +1200, Thomas Munro wrote: > On Tue, Apr 25, 2017 at 1:31 PM, Bruce Momjian wrote: > > I have committed the first draft of the Postgres 10 release notes. They > > are current as of two days ago, and I will keep them current. Please > > give

Re: [HACKERS] Still another race condition in recovery TAP tests

Michael Paquier writes: > On Mon, Sep 11, 2017 at 11:55 PM, Tom Lane wrote: >> Hm, I don't much like having it silently ignore files that are present; >> that seems like a foot-gun in the long run. What do you think of the >> attached? > That

Re: [HACKERS] GatherMerge misses to push target list

On Wed, Sep 6, 2017 at 10:04 AM, Amit Kapila wrote: > During my recent work on costing of parallel paths [1], I noticed that > we are missing to push target list below GatherMerge in some simple > cases like below. > I think this should be considered as a bug-fix for

Re: [HACKERS] PG 10 release notes

On Fri, Jun 2, 2017 at 04:05:44PM -0500, Jim Nasby wrote: > On 4/24/17 8:31 PM, Bruce Momjian wrote: > >I have committed the first draft of the Postgres 10 release notes. They > >are current as of two days ago, and I will keep them current. Please > >give me any feedback you have. > > > >The

Re: [HACKERS] PG 10 release notes

On Sat, Sep 9, 2017 at 12:39:43PM +0200, Adrien Nayrat wrote: > On 07/13/2017 04:36 PM, Adrien Nayrat wrote: > > Hello hackers, > > > > From: Peter Geoghegan > >> Date: Wed, 5 Jul 2017 15:19:57 -0700 > >> Subject: Re: [BUGS] BUG #14722: Segfault in tuplesort_heap_siftup, 32 bit >

Re: [HACKERS] SCRAM in the PG 10 release notes

On Wed, May 10, 2017 at 10:50:51PM -0400, Bruce Momjian wrote: > On Mon, May 1, 2017 at 08:12:51AM -0400, Robert Haas wrote: > > On Tue, Apr 25, 2017 at 10:16 PM, Bruce Momjian wrote: > > > Well, we could add "MD5 users are encouraged to switch to > > > SCRAM-SHA-256". Now

Re: [HACKERS] WAL logging problem in 9.4.3?

Hello, At Fri, 08 Sep 2017 16:30:01 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20170908.163001.53230385.horiguchi.kyot...@lab.ntt.co.jp> > > >> 2017-04-13 12:11:27.065 JST [85441] t/102_vacuumdb_stages.pl > > >> STATEMENT: ANALYZE; > > >>

Re: [HACKERS] Support to COMMENT ON DATABASE CURRENT_DATABASE

On Tue, Sep 12, 2017 at 1:11 PM, Jing Wang wrote: > Please find the rebased patch based on latest version in the attached file. Hi Jing It looks like you created dbname.sql and dbname.out files for a regression test but forgot to "git add" them to your branch before you

Re: [HACKERS] PG 10 release notes

On Tue, Sep 12, 2017 at 11:57 AM, Bruce Momjian wrote: > On Tue, Aug 1, 2017 at 08:53:51AM +1200, Thomas Munro wrote: >> "Add AFTER trigger transition tables to record changed rows (Kevin Grittner)" >> >> Any chance I could ask for a secondary author credit here? > > Sure,

Re: [HACKERS] Support to COMMENT ON DATABASE CURRENT_DATABASE

Hi Surafel, Please find the rebased patch based on latest version in the attached file. Regards, Jing Wang Fujitsu Australia comment_on_current_database_for_pgdump_v4.patch Description: Binary data comment_on_current_database_no_pgdump_v4.patch Description: Binary data -- Sent via

Re: [HACKERS] pgbench - minor fix for meta command only scripts

Hello Jeff, Shouldn't we use pg_usleep to ensure portability? it is defined for front-end code. But it returns void, so the error check will have to be changed. Attached v3 with pg_usleep called instead. I didn't see the problem before the commit I originally indicated , so I don't think

Re: [HACKERS] [Proposal] Allow users to specify multiple tables in VACUUM commands

On Mon, Sep 11, 2017 at 2:05 PM, Bossart, Nathan wrote: >> + if (i == InvalidAttrNumber) >> + ereport(ERROR, >> + (errcode(ERRCODE_UNDEFINED_COLUMN), >> +errmsg("column \"%s\" of relation \"%s\" does not >>

Re: [HACKERS] PG 10 release notes

Bruce Momjian writes: > On Fri, Jun 2, 2017 at 04:05:44PM -0500, Jim Nasby wrote: >> Can you change the attribution on >> Allow PL/Tcl functions to return composite types and sets >> to Karl Lehenbauer? > Done and backpatched. Sorry for the delay. I don't see this pushed to

Re: [HACKERS] Still another race condition in recovery TAP tests

On Mon, Sep 11, 2017 at 11:55 PM, Tom Lane wrote: > Hm, I don't much like having it silently ignore files that are present; > that seems like a foot-gun in the long run. What do you think of the > attached? That looks good to me. I have tried pretty hard to break it, but

Re: [HACKERS] Support to COMMENT ON DATABASE CURRENT_DATABASE

Hi Surafel, Sorry for that. Yes. The test case file is forgotten to be added into the previous patch. Kindly please use the updated patch in the attached file. Regards, Jing Wang Fujitsu Australia comment_on_current_database_no_pgdump_v4.1.patch Description: Binary data -- Sent via

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On 2017/09/11 19:45, Ashutosh Bapat wrote: > On Mon, Sep 11, 2017 at 12:16 PM, Amit Langote wrote: >> IMHO, we should make it the responsibility of the future patch to set a >> child PlanRowMark's prti to the direct parent's RT index, when we actually >> know that it's needed for something. We

[HACKERS] Removing wal_keep_segments as default configuration in PostgresNode.pm

Hi all, Right now, PostgresNode.pm uses this set of parameters when initializing a node: print $conf "\n# Added by PostgresNode.pm\n"; print $conf "fsync = off\n"; print $conf "restart_after_crash = off\n"; print $conf "log_line_prefix = '%m [%p] %q%a '\n"; print $conf

Re: [HACKERS] More flexible LDAP auth search filters?

On Tue, Sep 12, 2017 at 7:21 AM, Peter Eisentraut wrote: > On 9/8/17 13:24, Mark Cave-Ayland wrote: >> My weapon of choice for LDAP deployments on POSIX-based systems is >> Arthur De Jong's nss-pam-ldapd (https://arthurdejong.org/nss-pam-ldapd) >> which is far

Re: [HACKERS] [POC] hash partitioning

On Fri, Sep 8, 2017 at 6:10 PM, amul sul wrote: > On Fri, Sep 8, 2017 at 6:45 AM, Robert Haas wrote: >> >> On Mon, Sep 4, 2017 at 6:38 AM, amul sul wrote: >> > I've updated patch to use an extended hash function (Commit # >> >

Re: [HACKERS] pgbench - minor fix for meta command only scripts

Hello Jeff, Ok, the problem was a little bit more trivial than I thought. The issue is that under a low rate there may be no transaction in progress, however the wait procedure was relying on select's timeout. If nothing is active there is nothing to wait for, thus it was an active loop in

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Mon, Sep 11, 2017 at 2:16 PM, Amit Langote wrote: > On 2017/09/11 16:23, Ashutosh Bapat wrote: >> On Sat, Sep 9, 2017 at 6:28 AM, Robert Haas wrote: >>> I'm a bit suspicious about the fact that there are now executor >>> changes related to

Re: [HACKERS] [POC] Faster processing at Gather node

Thanks Rafia, Amit, now I understand the ideas behind the patch better. I'll see if I can look at the new one. -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On 2017/09/11 16:23, Ashutosh Bapat wrote: > On Sat, Sep 9, 2017 at 6:28 AM, Robert Haas wrote: >> I'm a bit suspicious about the fact that there are now executor >> changes related to the PlanRowMarks. If the rowmark's prti is now the >> intermediate parent's RT index

Re: [HACKERS] mysql_fdw + PG10: unrecognized node type: 217

Re: To Tom Lane 2017-09-11 <20170911083136.stdnc4w52wk3o...@msg.df7cb.de> > postgres=# select test_param_where(); > FEHLER: XX000: unrecognized node type: 217 > KONTEXT: SQL-Anweisung »select bfrom numbers where a=x« > PL/pgSQL-Funktion test_param_where() Zeile 6 bei SQL-Anweisung > ORT:

Re: [HACKERS] Remove 1MB size limit in tsvector

On Thu, 7 Sep 2017 23:08:14 +0200 Tomas Vondra wrote: > Hi, > > On 08/17/2017 12:23 PM, Ildus Kurbangaliev wrote: > > In my benchmarks when database fits into buffers (so it's > > measurement of the time required for the tsvectors conversion) it > > gives me these

Re: [HACKERS] Automatic testing of patches in commit fest

Hi Thomas, Great job! Here is a crazy idea. What if we write a script that would automatically return the patches that: 1) Are not in "Waiting on Author" status 2) Don't apply OR don't pass `make installcheck-world` ... to the "Waiting on Author" status and describe the problem through the

Re: [HACKERS] Setting pd_lower in GIN metapage

On Mon, Sep 11, 2017 at 12:43 PM, Michael Paquier wrote: > On Mon, Sep 11, 2017 at 4:07 PM, Amit Kapila wrote: >> I have prepared separate patches for hash and btree index. I think >> for another type of indexes, it is better to first fix the

Re: [HACKERS] mysql_fdw + PG10: unrecognized node type: 217

Re: Andres Freund 2017-09-11 <20170911090306.s7sj4uyr4t72w...@alap3.anarazel.de> > Could you pprint() the expression that's being initialized? (gdb) f 4 #4 0x5604ecedd124 in ExecInitNode (node=node@entry=0x5604ee884f80, estate=estate@entry=0x5604ee8c78a0, eflags=eflags@entry=16) at

Re: [HACKERS] Allow GiST opcalsses without compress\decompres functions

> 11 сент. 2017 г., в 12:57, Dmitriy Sarafannikov > написал(а): > Hi Andrew! Thanks for the patch, but patch > 0001-allow-uncompressed-Gist-2.patch no longer applies on current master > branch. > Please could you rebase it? Sure, see attachment. Thanks for looking

Re: [HACKERS] Setting pd_lower in GIN metapage

On Mon, Sep 11, 2017 at 5:40 PM, Amit Langote wrote: > On 2017/09/10 15:22, Michael Paquier wrote: >> On Sun, Sep 10, 2017 at 3:15 PM, Amit Kapila wrote: >>> On Sat, Sep 9, 2017 at 9:00 PM, Tom Lane wrote: Michael

Re: [HACKERS] Cached plans and statement generalization

On 09.09.2017 06:35, Thomas Munro wrote: On Fri, May 26, 2017 at 3:54 AM, Konstantin Knizhnik wrote: Attached please find rebased version of the autoprepare patch based on Tom's proposal (perform analyze for tree with constant literals and then replace them with

Re: [HACKERS] Red-black trees: why would anyone want preorder or postorder traversal?

Hi Tom, > In short, therefore, I propose we rip out the DirectWalk and InvertedWalk > options along with their support code, and then drop the portions of > test_rbtree that are needed to exercise them. Any objections? Doesn't sound like something that will be used any time soon. When and if it

Re: [HACKERS] psql: new help related to variables are not too readable

Tomas Vondra wrote: > > Finally, as vertical scrolling is mandatory, I would be fine with > > skipping lines with entries for readability, but it is just a matter of > > taste and I expect there should be half a dozen different opinions on > > the matter of formatting. > > FWIW, +1 to extra

Re: [HACKERS] Polyphase merge is obsolete

Hi, I planned to do some benchmarking on this patch, but apparently the patch no longer applies. Rebase please? regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Mon, Sep 11, 2017 at 12:16 PM, Amit Langote wrote: > On 2017/09/09 2:38, Ashutosh Bapat wrote: >> On Fri, Sep 8, 2017 at 11:17 AM, Amit Langote wrote: >>> I updated the patch to include just those changes. I'm not sure about >>> one of the Ashutosh's changes

Re: [HACKERS] Setting pd_lower in GIN metapage

On 2017/09/10 15:22, Michael Paquier wrote: > On Sun, Sep 10, 2017 at 3:15 PM, Amit Kapila wrote: >> On Sat, Sep 9, 2017 at 9:00 PM, Tom Lane wrote: >>> Michael Paquier writes: On Fri, Sep 8, 2017 at 5:24 AM, Tom Lane

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

On Thu, Sep 7, 2017 at 7:34 PM, Antonin Houska wrote: > Ashutosh Bapat wrote: > >> I have fixed the issues which were marked as TODOs in the attached >> patches. Also, I have included your test change patch in my series of >> patches. > > I've

Re: [HACKERS] WIP: Aggregation push-down

On Fri, Sep 8, 2017 at 7:04 PM, Antonin Houska wrote: > Ashutosh Bapat wrote: > >> On Thu, Aug 17, 2017 at 8:52 PM, Antonin Houska wrote: >> > Antonin Houska wrote: >> > >> >> Antonin Houska

Re: [HACKERS] mysql_fdw + PG10: unrecognized node type: 217

Re: Tom Lane 2017-09-10 <13662.1505077...@sss.pgh.pa.us> > Christoph Berg writes: > > I'm not sure if this is a bug in mysql_fdw, or in PG10: > > > ! ERROR: unrecognized node type: 217 > > Hm, nodetag 217 is T_List according to gdb. Wouldn't expect that > failure in very many

Re: [HACKERS] mysql_fdw + PG10: unrecognized node type: 217

Hi, On 2017-09-11 10:53:39 +0200, Christoph Berg wrote: > Re: To Tom Lane 2017-09-11 <20170911083136.stdnc4w52wk3o...@msg.df7cb.de> > > postgres=# select test_param_where(); > > FEHLER: XX000: unrecognized node type: 217 > > KONTEXT: SQL-Anweisung »select bfrom numbers where a=x« > >

Re: [HACKERS] expanding inheritance in partition bound order

Hi Amit, On 2017/09/11 16:16, Amit Khandekar wrote: > Thanks Amit for the patch. I am still reviewing it, but meanwhile > below are a few comments so far ... Thanks for the review. > + next_parted_idx += (list_length(*pds) - next_parted_idx - 1); > > I think this can be replaced just by : >

Re: [HACKERS] Automatic testing of patches in commit fest

Hi Tomas, > > Unless there are any objections to give this idea a try I'm willing to > > write and host a corresponding script. > > > That won't work until (2) is reliable enough. There are patches (for > example my "multivariate MCV lists and histograms") which fails to apply > only because the

Re: [HACKERS] Remove 1MB size limit in tsvector

On Mon, Sep 11, 2017 at 5:33 AM, Ildus Kurbangaliev wrote: > Moreover, RUM index > stores positions + lexemes, so it doesn't need tsvectors for ranked > search. As a result, tsvector becomes a storage for > building indexes (indexable type), not something that

Re: [HACKERS] [POC] hash partitioning

Robert Haas wrote: > On Mon, Sep 11, 2017 at 4:17 AM, Ashutosh Bapat > wrote: > >> Rebased 0002 against this commit & renamed to 0001, PFA. > > > > Given that we have default partition support now, I am wondering > > whether hash partitioned tables also should

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

On 2017/08/17 17:27, Etsuro Fujita wrote: On 2017/07/11 6:56, Robert Haas wrote: I have to admit that I'm a little bit fuzzy about why foreign insert routing requires all of these changes.  I think this patch would benefit from being accompanied by several paragraphs of explanation outlining

Re: [HACKERS] Re: proposal - using names as primary names of plpgsql function parameters instead $ based names

2017-09-11 9:46 GMT+02:00 Jeevan Chalke : > Hi Pavel, > > > On Sat, Sep 9, 2017 at 11:42 AM, Pavel Stehule > wrote: > >> Hi >> >> 2017-09-08 9:36 GMT+02:00 Jeevan Chalke : >> >>> Hi Pavel, >>> I like the

Re: [HACKERS] Parallel Append implementation

On Mon, Sep 11, 2017 at 4:49 PM, Amit Khandekar wrote: > On 8 September 2017 at 19:17, Amit Kapila wrote: >> >> In that case, why can't we keep the workers also process in same >> order, what is the harm in that? > > Because of the way the logic

Re: [HACKERS] [POC] hash partitioning

On Mon, Sep 11, 2017 at 4:17 AM, Ashutosh Bapat wrote: >> Rebased 0002 against this commit & renamed to 0001, PFA. > > Given that we have default partition support now, I am wondering > whether hash partitioned tables also should have default partitions. > The way

Re: [HACKERS] Constifying numeric.c's local vars

Andres Freund writes: > One large user of unnecessary non-constant static variables is > numeric.c. More out of curiosity - numeric is slow enough in itself to > make inlining not a huge win - I converted it to use consts. LGTM. > It's a bit ugly that some consts have to be

Re: [HACKERS] Automatic testing of patches in commit fest

On Mon, Sep 11, 2017 at 3:11 PM, Aleksander Alekseev wrote: > Hi Thomas, > > Great job! > > Here is a crazy idea. What if we write a script that would automatically > return the patches that: > > 1) Are not in "Waiting on Author" status > 2) Don't apply OR don't pass

Re: [HACKERS] Remove 1MB size limit in tsvector

On 09/11/2017 01:54 PM, Robert Haas wrote: > On Mon, Sep 11, 2017 at 5:33 AM, Ildus Kurbangaliev > wrote: >> Moreover, RUM index >> stores positions + lexemes, so it doesn't need tsvectors for ranked >> search. As a result, tsvector becomes a storage for >> building

Re: [HACKERS] Parallel Append implementation

On 8 September 2017 at 19:17, Amit Kapila wrote: > On Fri, Sep 8, 2017 at 3:59 PM, Amit Khandekar wrote: >> On 7 September 2017 at 11:05, Amit Kapila wrote: >>> On Thu, Aug 31, 2017 at 12:47 PM, Amit Khandekar

Re: [HACKERS] mysql_fdw + PG10: unrecognized node type: 217

Re: To Andres Freund 2017-09-11 <20170911095338.mqkiinkpk7gko...@msg.df7cb.de> > Re: Andres Freund 2017-09-11 > <20170911090306.s7sj4uyr4t72w...@alap3.anarazel.de> > > Could you pprint() the expression that's being initialized? > (gdb) p pprint(node) Andres helped me to produce a correct dump,

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Mon, Sep 11, 2017 at 6:45 AM, Ashutosh Bapat wrote: > So, all partitioned partitions are getting locked correctly. Am I > missing something? That's not a valid test. In that scenario, you're going to hold all the locks acquired by the planner, all the locks

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Mon, Sep 11, 2017 at 5:19 PM, Robert Haas wrote: > On Mon, Sep 11, 2017 at 6:45 AM, Ashutosh Bapat > wrote: >> So, all partitioned partitions are getting locked correctly. Am I >> missing something? > > That's not a valid test. In that

Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan

On 9/8/17 13:14, Simon Riggs wrote: > 2. Allow a SET to apply only for a single statement > SET guc1 = x, guc2 = y FOR stmt > e.g. SET max_parallel_workers = 4 FOR SELECT count(*) FROM bigtable > Internally a GUC setting already exists for a single use, via > GUC_ACTION_SAVE, so we just need to

Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan

Peter Eisentraut writes: > On 9/8/17 13:14, Simon Riggs wrote: >> 2. Allow a SET to apply only for a single statement >> SET guc1 = x, guc2 = y FOR stmt >> e.g. SET max_parallel_workers = 4 FOR SELECT count(*) FROM bigtable >> Internally a GUC setting already

Re: [HACKERS] Automatic testing of patches in commit fest

On 09/11/2017 11:41 AM, Aleksander Alekseev wrote: > Hi Thomas, > > Great job! > +1 > Here is a crazy idea. What if we write a script that would automatically > return the patches that: > > 1) Are not in "Waiting on Author" status > 2) Don't apply OR don't pass `make installcheck-world` > >

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On 2017/09/09 9:58, Robert Haas wrote: > I'm a bit suspicious about the fact that there are now executor > changes related to the PlanRowMarks. If the rowmark's prti is now the > intermediate parent's RT index rather than the top-parent's RT index, > it'd seem like that'd matter somehow. Maybe

[HACKERS] [PATCH] Overestimated filter cost and its mitigation

Hi hackers, Currently, cost of a filter with multiple clauses is estimated by summing up estimated cost of each clause. As long as a filter consists of simple clauses and its cost is fairly small, it works fine. However, when there exists some heavy clauses (like SubQuery or user-defined

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On 2017/09/09 2:38, Ashutosh Bapat wrote: > On Fri, Sep 8, 2017 at 11:17 AM, Amit Langote wrote: >> I updated the patch to include just those changes. I'm not sure about >> one of the Ashutosh's changes whereby the child PlanRowMark is also passed >> to expand_partitioned_rtentry() to use as the

Re: [HACKERS] Create replication slot in pg_basebackup if requested and not yet present

Hi, On Fri, Sep 08, 2017 at 10:30:20AM -0700, Jeff Janes wrote: > On Wed, Sep 6, 2017 at 9:22 AM, Peter Eisentraut < > peter.eisentr...@2ndquadrant.com> wrote: > > > On 8/18/17 05:28, Michael Banck wrote: > > >>> Rebased, squashed and slighly edited version attached. I've added this > > >>> to

Re: [HACKERS] expanding inheritance in partition bound order

Thanks Amit for the patch. I am still reviewing it, but meanwhile below are a few comments so far ... On 8 September 2017 at 15:53, Amit Langote wrote: > [PATCH 2/2] Make RelationGetPartitionDispatch expansion order > depth-first > > This is so as it matches what

Re: [HACKERS] Setting pd_lower in GIN metapage

On Mon, Sep 11, 2017 at 4:07 PM, Amit Kapila wrote: > I have prepared separate patches for hash and btree index. I think > for another type of indexes, it is better to first fix the pd_lower > issue. Just wondering (sorry I have not looked at your patch in details)...

Re: [HACKERS] Allow GiST opcalsses without compress\decompres functions

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 Hi Andrew! Thanks for the patch, but patch

Re: [HACKERS] [POC] Faster processing at Gather node

On Sat, Sep 9, 2017 at 8:14 AM, Amit Kapila wrote: > On Fri, Sep 8, 2017 at 11:07 PM, Alexander Kuzmenkov > wrote: >> Hi Rafia, >> >> I like the idea of reducing locking overhead by sending tuples in bulk. The >> implementation could probably

Re: [HACKERS] Create replication slot in pg_basebackup if requested and not yet present

Hi, On Fri, Sep 08, 2017 at 08:41:56AM +0200, Michael Banck wrote: > Am Mittwoch, den 06.09.2017, 12:22 -0400 schrieb Peter Eisentraut: > > On 8/18/17 05:28, Michael Banck wrote: > > > > > Rebased, squashed and slighly edited version attached. I've added this > > > > > to the 2017-07 commitfest

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Sat, Sep 9, 2017 at 6:28 AM, Robert Haas wrote: > On Fri, Sep 8, 2017 at 1:38 PM, Ashutosh Bapat > wrote: >>> I also confirmed that the partition-pruning patch set works fine with this >>> patch instead of the patch on that thread with

Re: [HACKERS] Re: proposal - using names as primary names of plpgsql function parameters instead $ based names

Hi Pavel, On Sat, Sep 9, 2017 at 11:42 AM, Pavel Stehule wrote: > Hi > > 2017-09-08 9:36 GMT+02:00 Jeevan Chalke : > >> Hi Pavel, >> I like the idea of using parameter name instead of $n symbols. >> >> However, I am slightly worried

Re: [HACKERS] Setting pd_lower in GIN metapage

On Mon, Sep 11, 2017 at 7:18 AM, Amit Kapila wrote: > On Sun, Sep 10, 2017 at 9:56 PM, Tom Lane wrote: >> Amit Kapila writes: >>> On Sun, Sep 10, 2017 at 11:52 AM, Michael Paquier >>> wrote:

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

On Sun, Sep 10, 2017 at 6:25 PM, Stephen Frost wrote: > * Michael Paquier (michael.paqu...@gmail.com) wrote: >> As there begins to be many switches of this kind and much code >> duplication, I think that some refactoring into a more generic switch >> infrastructure would be

Re: [HACKERS] Still another race condition in recovery TAP tests

Michael Paquier writes: > On Sun, Sep 10, 2017 at 12:38 AM, Tom Lane wrote: >> The specific case we need to allow is "ENOENT on a file/dir that was >> there a moment ago". I think it still behooves us to complain about >> anything else. If you

Re: [HACKERS] [POC] hash partitioning

On Mon, Sep 11, 2017 at 8:00 AM, Alvaro Herrera wrote: > How difficult/tedious/troublesome would be to install the missing > partitions if you set hash partitioning with a default partition and > only later on notice that some partitions are missing? I think if the >

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Mon, Sep 11, 2017 at 8:07 AM, Ashutosh Bapat wrote: > I see the same thing when I use prepare and execute Hmm. Well, that's good, but it doesn't prove there's no bug. We have to understand where and why it's getting locked to know whether the behavior will

Re: [HACKERS] CLUSTER command progress monitor

On Sun, Sep 10, 2017 at 10:36 PM, Tatsuro Yamada wrote: > Thanks for the comment. > > As you know, CLUSTER command uses SEQ SCAN or INDEX SCAN as a scan method by > cost estimation. In the case of SEQ SCAN, these two phases not overlap. > However, in INDEX SCAN, it

Re: [HACKERS] Fix performance degradation of contended LWLock on NUMA

Hi, On 09/08/2017 03:35 PM, Sokolov Yura wrote: I'm seeing -M prepared: Up to 11% improvement -M prepared -S: No improvement, no regression ("noise") -M prepared -N: Up to 12% improvement for all runs the improvement shows up the closer you get to the number of CPU threads, or above. Although

Re: [HACKERS] The case for removing replacement selection sort

On Sun, Sep 10, 2017 at 9:39 PM, Peter Geoghegan wrote: > To be clear, you'll still need to set replacement_sort_tuples high > when testing RS, to make sure that we really use it for at least the > first run when we're expected to. (There is no easy way to have > testing

Re: [HACKERS] Automatic testing of patches in commit fest

On 09/11/2017 03:01 PM, Aleksander Alekseev wrote: > Hi Tomas, > >>> Unless there are any objections to give this idea a try I'm willing to >>> write and host a corresponding script. >>> >> That won't work until (2) is reliable enough. There are patches >> (for example my "multivariate MCV

Re: [HACKERS] UPDATE of partition key

On Thu, Sep 7, 2017 at 11:41 AM, Amit Khandekar wrote: > On 6 September 2017 at 21:47, Dilip Kumar wrote: > Actually, since transition tables came in, the functions like > ExecARUpdateTriggers() or ExecARInsertTriggers() have this additional >

Re: [HACKERS] psql - add special variable to reflect the last query status

I think you're overly optimistic to believe that every failure will have a SQLSTATE; I don't think that's true for libpq-reported errors, such as connection loss. Yep, I thought I was optimistic:-) Can I add a special SQLSTATE for that situation where libpq did not report an error? Meh.

Re: [HACKERS] pgbench tap tests & minor fixes.

On 09/11/2017 01:58 PM, Tom Lane wrote: > Andrew Dunstan writes: >> On 09/08/2017 09:40 AM, Tom Lane wrote: >>> Like you, I'm a bit worried about the code for extracting an exit >>> status from IPC::Run::run. We'll have to keep an eye on the buildfarm >>> for a

Re: [HACKERS] pgbench - minor fix for meta command only scripts

On Mon, Sep 11, 2017 at 1:49 AM, Fabien COELHO wrote: > > Hello Jeff, > > Ok, the problem was a little bit more trivial than I thought. > > The issue is that under a low rate there may be no transaction in > progress, however the wait procedure was relying on select's

Re: [HACKERS] psql - add special variable to reflect the last query status

2017-09-11 20:46 GMT+02:00 Fabien COELHO : > > I think you're overly optimistic to believe that every failure will have a SQLSTATE; I don't think that's true for libpq-reported errors, such as connection loss. >>> >> Yep, I thought I was optimistic:-) Can I add

Re: [HACKERS] assorted code cleanup

On 9/7/17 14:53, Tom Lane wrote: > Peter Eisentraut writes: >> On 9/5/17 15:32, Tom Lane wrote: >>> I do agree with the idea that we should use the * notation in cases where >>> the reader might otherwise think that a plain function was being invoked, >>> ie I

Re: [HACKERS] More flexible LDAP auth search filters?

On 9/8/17 13:24, Mark Cave-Ayland wrote: > My weapon of choice for LDAP deployments on POSIX-based systems is > Arthur De Jong's nss-pam-ldapd (https://arthurdejong.org/nss-pam-ldapd) > which is far more flexible than pam_ldap and fixes a large number of > bugs, including the tendency for pam_ldap

Re: [HACKERS] The case for removing replacement selection sort

On Wed, Sep 6, 2017 at 2:55 PM, Peter Geoghegan wrote: > On Wed, Sep 6, 2017 at 2:47 PM, Thomas Munro > wrote: >>> I attach a patch to remove replacement selection, which I'll submit to CF 1. >> >> This breaks the documentation build, because >>

Re: [HACKERS] More flexible LDAP auth search filters?

On 9/8/17 21:31, Thomas Munro wrote: > +if ($^O eq 'darwin') > +{ > + $slapd = '/usr/local/opt/openldap/libexec/slapd'; > + $ldap_schema_dir = '/usr/local/etc/openldap/schema'; > +} > > I'm guessing this is the MacPorts location, and someone from that > other tribe that uses Brew can

Re: [HACKERS] The case for removing replacement selection sort

On Mon, Sep 11, 2017 at 11:47 AM, Tomas Vondra wrote: > The question is what is the optimal replacement_sort_tuples value? I > assume it's the number of tuples that effectively uses CPU caches, at > least that's what our docs say. So I think you're right it to 1B

Re: [HACKERS] The case for removing replacement selection sort

On Mon, Sep 11, 2017 at 8:32 AM, Robert Haas wrote: > On Sun, Sep 10, 2017 at 9:39 PM, Peter Geoghegan wrote: >> To be clear, you'll still need to set replacement_sort_tuples high >> when testing RS, to make sure that we really use it for at least the >>

Re: [HACKERS] The case for removing replacement selection sort

On Mon, Sep 11, 2017 at 8:50 AM, Robert Haas wrote: > On Mon, Sep 11, 2017 at 11:47 AM, Tomas Vondra > wrote: >> The question is what is the optimal replacement_sort_tuples value? I >> assume it's the number of tuples that effectively uses CPU

Re: [HACKERS] Automatic testing of patches in commit fest

On 2017-09-11 02:12, Thomas Munro wrote: On Mon, Sep 11, 2017 at 11:40 AM, Michael Paquier wrote: Thomas Munro has hacked up a prototype of application testing automatically if patches submitted apply and build: http://commitfest.cputube.org/ I should add: this is

Re: [HACKERS] The case for removing replacement selection sort

On Mon, Sep 11, 2017 at 8:17 AM, Tomas Vondra wrote: > Overall I think the results show quite significant positive impact of > the patch. There are a few cases of regression, but ISTM those may > easily be noise as it's usually 0.03 vs 0.04 second, or something. I'll

Re: [HACKERS] [POC] hash partitioning

On Mon, Sep 11, 2017 at 5:30 PM, Alvaro Herrera wrote: > Robert Haas wrote: > > On Mon, Sep 11, 2017 at 4:17 AM, Ashutosh Bapat > > wrote: > > >> Rebased 0002 against this commit & renamed to 0001, PFA. > > > > > > Given that we have

Re: [HACKERS] The case for removing replacement selection sort

On 09/11/2017 05:32 PM, Robert Haas wrote: > On Sun, Sep 10, 2017 at 9:39 PM, Peter Geoghegan wrote: >> To be clear, you'll still need to set replacement_sort_tuples high >> when testing RS, to make sure that we really use it for at least the >> first run when we're expected to.

Re: [HACKERS] psql - add special variable to reflect the last query status

Fabien COELHO writes: > Small v7 update, sorry for the noise. Hm. Looking closer at this, I see that it doesn't work so well after all to put the variable-setting code in ProcessResult: that fails to cover the ExecQueryUsingCursor code path. And it also fails to cover

Re: [HACKERS] pg_stat_wal_write statistics view

On Wed, Sep 6, 2017 at 9:16 AM, Haribabu Kommi wrote: > > Attached the latest patch and performance report. > While looking into the patch, I realized that a normal backend has to check almost 10 if conditions at worst case inside XLogWrite(6 in am_background_process

Re: [HACKERS] The case for removing replacement selection sort

On Mon, Sep 11, 2017 at 8:47 AM, Tomas Vondra wrote: > The question is what is the optimal replacement_sort_tuples value? See my remarks to Robert just now. I think that it's incredibly hard to set replacement_sort_tuples sensibly in 9.6. As of Postgres 10, it is

  1   2   >