Re: [HACKERS] Time to drop old-style (V0) functions?

On 2017-02-28 23:15:15 -0800, Andres Freund wrote: > On 2016-12-08 13:34:41 -0800, Andres Freund wrote: > > Hi, > > > > I'm wondering if it's not time for $subject: > > - V0 causes confusion / weird crashes when PG_FUNCTION_INFO_V1 was > > forgotten > > - They have us keep weird hacks around

Re: [HACKERS] Time to drop old-style (V0) functions?

On 2016-12-08 13:34:41 -0800, Andres Freund wrote: > Hi, > > I'm wondering if it's not time for $subject: > - V0 causes confusion / weird crashes when PG_FUNCTION_INFO_V1 was > forgotten > - They have us keep weird hacks around just for the sake of testing V0 > - they actually cost performance,

Re: [HACKERS] Proposal : Parallel Merge Join

On Wed, Mar 1, 2017 at 11:24 AM, Dilip Kumar wrote: > On Wed, Mar 1, 2017 at 11:13 AM, Amit Kapila wrote: >> I think for now we can keep the parallel safety check for cheapest >> inner path, though it will be of use only for the very first time we

Re: [HACKERS] [GENERAL] C++ port of Postgres

Hi, On 2017-02-28 23:42:45 -0500, Peter Eisentraut wrote: > On 1/26/17 22:46, Andres Freund wrote: > > On 2016-09-30 15:24:09 -0400, Peter Eisentraut wrote: > >> Yeah, I have committed a few of the patches now and I'll close the CF > >> entry now. Thanks for your research. > > > > Are you

Re: [HACKERS] Proposal : Parallel Merge Join

On Wed, Mar 1, 2017 at 11:13 AM, Amit Kapila wrote: > I think for now we can keep the parallel safety check for cheapest > inner path, though it will be of use only for the very first time we > compare the paths in that loop. I am not sure if there is any other > better

Re: [HACKERS] Proposal : Parallel Merge Join

On Tue, Feb 28, 2017 at 9:28 PM, Dilip Kumar wrote: > On Mon, Feb 27, 2017 at 10:27 AM, Amit Kapila wrote: >> Okay, but in that case don't you think it is better to consider the >> parallel safety of cheapest_total_inner only when we don't find any

Re: [HACKERS] Faster methods for getting SPI results (460% improvement)

On 1/24/17 10:43 PM, Jim Nasby wrote: I strongly suggest making this design effort a separate thread, and focusing on the SPI improvements that give "free" no-user-action performance boosts here. Fair enough. I posted the SPI portion of that yesterday. That should be useful for pl/R and

Re: [HACKERS] Performance degradation in TPC-H Q18

On Wed, Mar 1, 2017 at 10:53 AM, Andres Freund wrote: > On 2017-03-01 10:47:45 +0530, Kuntal Ghosh wrote: >> if (insertdist > curdist) >> { >> swap the entry to be inserted with the current entry. >> Try to insert the current entry in the same logic. >> } >> >> So, the second

Re: [HACKERS] Radix tree for character conversion

On Tue, Feb 28, 2017 at 5:34 PM, Kyotaro HORIGUCHI wrote: > At Tue, 28 Feb 2017 15:20:06 +0900, Michael Paquier > wrote in > >> +conv.o: conv.c char_converter.c >>

Re: [HACKERS] [POC] hash partitioning

On Tue, Feb 28, 2017 at 8:03 PM, Yugo Nagata wrote: > Hi all, > > Now we have a declarative partitioning, but hash partitioning is not > implemented yet. Attached is a POC patch to add the hash partitioning > feature. I know we will need more discussions about the syntax and

Re: [HACKERS] Performance degradation in TPC-H Q18

On 2017-03-01 10:47:45 +0530, Kuntal Ghosh wrote: > if (insertdist > curdist) > { > swap the entry to be inserted with the current entry. > Try to insert the current entry in the same logic. > } > > So, the second approach will not cause all the followers to be shifted by 1. How not? You'll have

Re: [HACKERS] Performance degradation in TPC-H Q18

On Wed, Mar 1, 2017 at 9:38 AM, Andres Freund wrote: > Hi, > > On 2017-03-01 09:33:07 +0530, Kuntal Ghosh wrote: >> On Wed, Mar 1, 2017 at 9:19 AM, Andres Freund wrote: >> >> So, I was looking for other alternatives and I've found one called >> >>

Re: [HACKERS] Performance degradation in TPC-H Q18

On Wed, Mar 1, 2017 at 9:33 AM, Kuntal Ghosh wrote: > On Wed, Mar 1, 2017 at 9:19 AM, Andres Freund wrote: >> That's without the patch in >> http://archives.postgresql.org/message-id/20161123083351.5vramz52nmdokhzz%40alap3.anarazel.de >> ? With

Re: [HACKERS] brin autosummarization -- autovacuum "work items"

On Wed, Mar 1, 2017 at 5:58 PM, Alvaro Herrera wrote: > I think one of the most serious issues with BRIN indexes is how they > don't get updated automatically as the table is filled. This patch > attempts to improve on that. During brininsert() time, we check whether >

Re: [HACKERS] [POC] hash partitioning

On Tue, Feb 28, 2017 at 8:03 PM, Yugo Nagata wrote: > Hi all, > > Now we have a declarative partitioning, but hash partitioning is not > implemented yet. Attached is a POC patch to add the hash partitioning > feature. I know we will need more discussions about the syntax and

Re: [HACKERS] patch proposal

On Wed, Mar 1, 2017 at 1:14 AM, Venkata B Nagothi wrote: > Hi David, > > On Tue, Jan 31, 2017 at 6:49 AM, David Steele wrote: > >> On 1/27/17 3:19 AM, Venkata B Nagothi wrote: >> >> > I will be adding the tests in >> >

[HACKERS] brin autosummarization -- autovacuum "work items"

I think one of the most serious issues with BRIN indexes is how they don't get updated automatically as the table is filled. This patch attempts to improve on that. During brininsert() time, we check whether we're inserting the first item on the first page in a range. If we are, request

Re: [HACKERS] rename pg_log directory?

On 2/28/17 06:07, Magnus Hagander wrote: > server_log seems like a better choice then I think. So +1 for that. > > In theory cluster_log since it's a "cluster level log", but given how > many people already get confused by the term cluster being used that > way, I think that while maybe

Re: [HACKERS] Should we cacheline align PGXACT?

On Tue, Feb 28, 2017 at 11:44 PM, Simon Riggs wrote: > On 28 February 2017 at 11:34, Ashutosh Sharma > wrote: > > >> So, Here are the pgbench results I got with ' >> *reduce_pgxact_access_AtEOXact.v2.patch*' on a read-write workload. >> > > Thanks

Re: [HACKERS] rename pg_log directory?

On 2/27/17 09:51, Tom Lane wrote: > No objection to the basic point, but "log" seems perhaps a little too > generic to me. Would something like "server_log" be better? Well, "log" is pretty well established. There is /var/log, and if you unpack a, say, Kafka or Cassandra distribution, they also

Re: [HACKERS] PATCH: two slab-like memory allocators

On 2017-02-28 20:18:35 -0800, Andres Freund wrote: > - Andres, hoping the buildfarm turns greener Oh well, that didn't work. Investigating. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] PATCH: two slab-like memory allocators

On 2017-02-28 10:41:22 -0800, Andres Freund wrote: > Hi, > > On 2017-02-27 23:44:20 -0800, Andres Freund wrote: > > *preliminary* patch attached. This needs a good bit of polishing > > (primarily comment work, verifying that valgrind works), but I'm too > > tired now. > > > > I'm not quite sure

Re: [HACKERS] Performance degradation in TPC-H Q18

Hi, On 2017-03-01 09:33:07 +0530, Kuntal Ghosh wrote: > On Wed, Mar 1, 2017 at 9:19 AM, Andres Freund wrote: > >> So, I was looking for other alternatives and I've found one called > >> RobinHood hashing. > > > > simplehash.h implements robin hood hashing. > But, it doesn't

Re: [HACKERS] Performance degradation in TPC-H Q18

On Wed, Mar 1, 2017 at 9:19 AM, Andres Freund wrote: > On 2017-03-01 09:13:15 +0530, Kuntal Ghosh wrote: >> On Wed, Mar 1, 2017 at 8:48 AM, Andres Freund wrote: >> >> BTW, another option to consider is lowering the target fillfactor. >> >> IIRC, Kuntal

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

> > >> >> Alternatively if the structure must really be kept, then deal with errors >> in a first switch, read value *after* switch and deal with other errors >> there, then start a second switch, and adjust the documentation accordingly? >> >> switch >> errors >> read >> if >>

Re: [HACKERS] Performance degradation in TPC-H Q18

On 2017-03-01 09:21:47 +0530, Robert Haas wrote: > On Wed, Mar 1, 2017 at 8:48 AM, Andres Freund wrote: > >> BTW, another option to consider is lowering the target fillfactor. > >> IIRC, Kuntal mentioned to me that cranking it down seemed to fix the > >> issue. Obviously,

Re: [HACKERS] perlcritic

I posted this about 18 months ago but then ran out of steam. In the meantime, some people have been going around doing various Perl code cleanups in parts of the code, so it seems it makes sense to proceed with this. We use "use strict" everywhere now, so some of the original patch has gone

Re: [HACKERS] Performance degradation in TPC-H Q18

On Wed, Mar 1, 2017 at 8:48 AM, Andres Freund wrote: >> BTW, another option to consider is lowering the target fillfactor. >> IIRC, Kuntal mentioned to me that cranking it down seemed to fix the >> issue. Obviously, it's better to detect when we need a lower >> fillfactor

Re: [HACKERS] Performance degradation in TPC-H Q18

On 2017-03-01 09:13:15 +0530, Kuntal Ghosh wrote: > On Wed, Mar 1, 2017 at 8:48 AM, Andres Freund wrote: > >> BTW, another option to consider is lowering the target fillfactor. > >> IIRC, Kuntal mentioned to me that cranking it down seemed to fix the > >> issue. Obviously,

Re: [HACKERS] SQL/JSON in PostgreSQL

> > >>> >> Good work - it will be pretty big patch. >> >> There is a intersection with implementation of XMLTABLE. I prepared a >> executor infrastructure. So it can little bit reduce size of this patch. >> > > we considered your XMLTABLE patch, but it's itself pretty big and in > unknown state.

Re: [HACKERS] Performance degradation in TPC-H Q18

On Wed, Mar 1, 2017 at 8:48 AM, Andres Freund wrote: >> BTW, another option to consider is lowering the target fillfactor. >> IIRC, Kuntal mentioned to me that cranking it down seemed to fix the >> issue. Obviously, it's better to detect when we need a lower >> fillfactor

Re: [HACKERS] PATCH: Make pg_stop_backup() archive wait optional

On 2/28/17 10:22 PM, Robert Haas wrote: > On Tue, Feb 28, 2017 at 6:22 AM, David Steele wrote: I'm not sure that's the case. It seems like it should lock just as multiple backends would now. One process would succeed and the others would error. Maybe I'm

Re: [HACKERS] some dblink refactoring

On Tue, Feb 28, 2017 at 10:09 PM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > Here is a patch to refactor some macro hell in dblink. > > This patch was discussed in the background sessions thread as a > prerequisite for some work there, but I figure I'll make a separate > thread

Re: [HACKERS] PATCH: Make pg_stop_backup() archive wait optional

On Tue, Feb 28, 2017 at 6:22 AM, David Steele wrote: >>> I'm not sure that's the case. It seems like it should lock just as >>> multiple backends would now. One process would succeed and the others >>> would error. Maybe I'm missing something? >> >> Hm, any errors

Re: [HACKERS] cast result of copyObject()

> The problem this patch would address is that currently you can write > > SomeNode *x = ...; > > ... > > > OtherNode *y = copyObject(x); > > and there is no notice about that potential mistake. > > This patch makes that an error. > > If you are sure about what you are doing, you can add a

Re: [HACKERS] Performance degradation in TPC-H Q18

On 2017-03-01 08:42:35 +0530, Robert Haas wrote: > On Tue, Feb 28, 2017 at 11:16 PM, Andres Freund wrote: > >> To me, it seems like a big problem that we have large, unfixed > >> performance regressions with simplehash four months after it went in. > > > > Yea, I agree. I'm

[HACKERS] use SQL standard error code for nextval

The SQL standard defines a separate error code for nextval exhausting the sequence space. I haven't found any discussion of this in the archives, so it seems this was just not considered or not yet in existence when the error codes were introduced. Here is a patch to correct it. -- Peter

Re: [HACKERS] Performance degradation in TPC-H Q18

On Tue, Feb 28, 2017 at 11:16 PM, Andres Freund wrote: >> To me, it seems like a big problem that we have large, unfixed >> performance regressions with simplehash four months after it went in. > > Yea, I agree. I'm fairly sure that the patch I posted in that thread >

[HACKERS] some dblink refactoring

Here is a patch to refactor some macro hell in dblink. This patch was discussed in the background sessions thread as a prerequisite for some work there, but I figure I'll make a separate thread for it to give everyone interested in dblink a chance to respond separate from the other thread. --

Re: [HACKERS] port of INSTALL file generation to XSLT

On 2/28/17 08:57, Magnus Hagander wrote: > It appears we need pandoc 1.13 to get the good output. This won't be > available until Debian stretch. > > So for PG10, I propose the attached revised patch which keeps using lynx > but uses xsltproc instead of jade. > > > It is

[HACKERS] allow referring to functions without arguments when unique

This is the "grand finale" that goes on top of the "DROP FUNCTION of multiple functions" patch set. The purpose is to allow referring to functions without having to spell out the argument list, when the function name is unique. This is especially useful when having to operate on "business logic"

Re: [HACKERS] background sessions

> For additional entertainment, I include patches that integrate > background sessions into dblink. So dblink can open a connection to a > background session, and then you can use the existing dblink functions > to send queries, read results, etc. People use dblink to make > self-connections to

Re: [HACKERS] New Committer - Andrew Gierth

On Tue, Feb 28, 2017 at 11:52 PM, Stephen Frost wrote: > Greetings! > > The PostgreSQL committers would like to welcome Andrew Gierth as a new > committer for the PostgreSQL project. > Congratulations! -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com

Re: [HACKERS] Creation of "Future" commit fest, named 2017-07

On Tue, Feb 28, 2017 at 9:28 AM, David Steele wrote: > On 2/27/17 7:27 PM, Michael Paquier wrote: >> On Tue, Feb 28, 2017 at 9:21 AM, David Steele wrote: >>> Looks like it's me, then. I don't seem to have admin privileges to >>> close the commitfest or

Re: [HACKERS] [POC] hash partitioning

Nagata-san, On 2017/02/28 23:33, Yugo Nagata wrote: > Hi all, > > Now we have a declarative partitioning, but hash partitioning is not > implemented yet. Attached is a POC patch to add the hash partitioning > feature. I know we will need more discussions about the syntax and other >

Re: [HACKERS] help to identify the reason that extension's C function returns array get segmentation fault

Thanks for your clues. The system I have used to debug the code is x86 64bit based, Ubuntu 1404 and postgres 9.3.13, I have revised the code and it looks like as following: Datum vquery(PG_FUNCTION_ARGS) { int array_len = PG_GETARG_INT32(0); int64 * node_ids; ArrayType * retarr; Datum * vals ;

[HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall

Subject changed for better context of the patch. (was - Re: Question about grant create on database and pg_dump/pg_dumpall) On Fri, Sep 30, 2016 at 12:29 AM, Tom Lane wrote: > >1. pg_dump without --create continues to do what it does today, ie it just >dumps

[HACKERS] PATCH: Configurable file mode mask

PostgreSQL currently requires the file mode mask (umask) to be 0077. However, this precludes the possibility of a user in the postgres group performing a backup (or whatever). Now that pg_start_backup()/pg_stop_backup() privileges can be delegated to an unprivileged user, it makes sense to also

Re: [HACKERS] Declarative partitioning optimization for large amount of partitions

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

[HACKERS] [PATCH] Use $ parameters as replacement characters for pg_stat_statements

Hi, Currently pg_stat_statements replaces constant values with ? characters. I've seen this be a problem on multiple occasions, in particular since it conflicts with the use of ? as an operator. I'd like to propose changing the replacement character from ? to instead be a parameter (like $1).

[HACKERS] Adding support for Default partition in partitioning

Hello, Currently inserting the data into a partitioned table that does not fit into any of its partitions is not allowed. The attached patch provides a capability to add a default partition to a list partitioned table as follows. postgres=# CREATE TABLE list_partitioned ( a int ) PARTITION

Re: [HACKERS] PassDownLimitBound for ForeignScan/CustomScan [take-2]

The attached patch is rebased version of pass-down LIMIT clause patch, which was forgotten to register on the last CF. It allows to inform required number of rows to the sub-plans not only ones we have individually handled at pass_down_bound(). Its primary target is control of number of remote

Re: [HACKERS] Other formats in pset like markdown, rst, mediawiki

There it is, what i have. I need i small help with psql.out, because \pset format wrapped. I don`t know, how to have it in fixed width. 2017-02-28 14:23 GMT+01:00 Jan Michálek : > Current state is something like this (diff is attached). > I currently haven`t regression

Re: [HACKERS] Disallowing multiple queries per PQexec()

On 2017-02-28 15:59:08 +0100, Andreas Karlsson wrote: > On 02/28/2017 03:13 PM, Bruce Momjian wrote: > > I might have added that one; the text is: > > > > Consider disallowing multiple queries in PQexec() > > as an additional barrier to SQL injection attacks > > > > and it is a

Re: [HACKERS] SQL/JSON in PostgreSQL

On Tue, Feb 28, 2017 at 10:55 PM, Pavel Stehule wrote: > Hi > > > 2017-02-28 20:08 GMT+01:00 Oleg Bartunov : > >> Hi there, >> >> >> Attached patch is an implementation of SQL/JSON data model from SQL-2016 >> standard (ISO/IEC 9075-2:2016(E)), which

Re: [HACKERS] SQL/JSON in PostgreSQL

Hi 2017-02-28 20:08 GMT+01:00 Oleg Bartunov : > Hi there, > > > Attached patch is an implementation of SQL/JSON data model from SQL-2016 > standard (ISO/IEC 9075-2:2016(E)), which was published 2016-12-15 and is > available only for purchase from ISO web site ( >

Re: [HACKERS] Logical replication existing data copy

On 2017-02-28 07:38, Erik Rijkers wrote: On 2017-02-27 15:08, Petr Jelinek wrote: 0001-Use-asynchronous-connect-API-in-libpqwalreceiver.patch + 0002-Fix-after-trigger-execution-in-logical-replication.patch +

[HACKERS] Cost model for parallel CREATE INDEX

There are a couple of open items for the parallel CREATE INDEX patch that at this point represent blockers to commit, IMV. The first is around a deficiency in the shared refcount mechanism, which is well understood and doesn't need to be rehashed on this thread. The second is the cost model, which

[HACKERS] SQL/JSON in PostgreSQL

Hi there, Attached patch is an implementation of SQL/JSON data model from SQL-2016 standard (ISO/IEC 9075-2:2016(E)), which was published 2016-12-15 and is available only for purchase from ISO web site ( https://www.iso.org/standard/63556.html). Unfortunately I didn't find any public sources of

Re: [HACKERS] PATCH: two slab-like memory allocators

Hi, On 2017-02-27 23:44:20 -0800, Andres Freund wrote: > *preliminary* patch attached. This needs a good bit of polishing > (primarily comment work, verifying that valgrind works), but I'm too > tired now. > > I'm not quite sure how to deal with mmgr/README - it's written as kind > of a

Re: [HACKERS] New Committer - Andrew Gierth

On Tue, Feb 28, 2017 at 01:22:22PM -0500, Stephen Frost wrote: > Greetings! > > The PostgreSQL committers would like to welcome Andrew Gierth as a > new committer for the PostgreSQL project. Congratulations! Best, David. -- David Fetter http://fetter.org/ Phone: +1

Re: [HACKERS] New Committer - Andrew Gierth

Hi, On 2017-02-28 13:22:22 -0500, Stephen Frost wrote: > Greetings! > > The PostgreSQL committers would like to welcome Andrew Gierth as a new > committer for the PostgreSQL project. > > Andrew - welcome! Congratulations Andrew! We now have two Andrews and one Andres amongst the

[HACKERS] New Committer - Andrew Gierth

Greetings! The PostgreSQL committers would like to welcome Andrew Gierth as a new committer for the PostgreSQL project. Andrew - welcome! Thanks! Stephen signature.asc Description: Digital signature

Re: [HACKERS] Should we cacheline align PGXACT?

On 28 February 2017 at 11:34, Ashutosh Sharma wrote: > So, Here are the pgbench results I got with ' > *reduce_pgxact_access_AtEOXact.v2.patch*' on a read-write workload. > Thanks for performing a test. I see a low yet noticeable performance gain across the board on

Re: [HACKERS] avoid bloat from CREATE INDEX CONCURRENTLY

On 28 February 2017 at 13:30, Tom Lane wrote: > Simon Riggs writes: >> On 28 February 2017 at 13:05, Tom Lane wrote: >>> Um ... isn't there a transaction boundary there anyway? > >> Yes, the patch releases the snapshot early, so it

Re: [HACKERS] Allow pg_dumpall to work without pg_authid

On 28 February 2017 at 16:12, Stephen Frost wrote: > Robert, > > * Robert Haas (robertmh...@gmail.com) wrote: >> On Sun, Feb 19, 2017 at 12:24 AM, Robins Tharakan wrote: >> > I would like to work on a patch to accommodate restricted environments >> >

Re: [HACKERS] Performance degradation in TPC-H Q18

Hi, On 2017-02-26 19:30:32 +0530, Robert Haas wrote: > On Wed, Feb 22, 2017 at 11:23 AM, Kuntal Ghosh > wrote: > > While conducting the experiments for parallelism, Rafia came across a > > hang in Q18 when plan uses partial and finalize hash aggregate. This > > could

Re: [HACKERS] REINDEX CONCURRENTLY 2.0

Hi, Here is a third take on this feature, heavily based on Michael Paquier's 2.0 patch. This time the patch does not attempt to preserve the index oids, but instead creates new indexes and moves all dependencies from the old indexes to the new before dropping the old ones. The only downside

[HACKERS] update comments about CatalogUpdateIndexes

Hi, commit 2f5c9d9c9ce removed CatalogUpdateIndexes and replaced it with CatalogTupleInsert/CatalogTupleUpdate, which do both the operation and index update. But there remained three places in comments still referencing the removed CatalogUpdateIndexes. Attached is a patch fixing those

Re: [HACKERS] [PATCH] SortSupport for macaddr type

Hi Julien, Thanks for the expedient reply, even after I'd dropped the ball for so long :) > Indeed, I should have checked more examples :/ There > isn't any clear pattern for this, so I guess any one > would be ok. Yeah, agreed. If it's alright with you, I ended up moving the naming back to

Re: [HACKERS] Allow pg_dumpall to work without pg_authid

Robert, * Robert Haas (robertmh...@gmail.com) wrote: > On Sun, Feb 19, 2017 at 12:24 AM, Robins Tharakan wrote: > > I would like to work on a patch to accommodate restricted environments (such > > as AWS RDS Postgres) which don't allow pg_authid access since their > >

Re: [HACKERS] Proposal : Parallel Merge Join

On Mon, Feb 27, 2017 at 10:27 AM, Amit Kapila wrote: > Okay, but in that case don't you think it is better to consider the > parallel safety of cheapest_total_inner only when we don't find any > cheap parallel_safe innerpath by reducing the sort keys? Well, we can do

Re: [HACKERS] Parallel bitmap heap scan

On Sun, Feb 26, 2017 at 9:26 PM, Robert Haas wrote: > I'm not entirely sure about the calling convention for > tbm_free_shared_area() but the rest seems OK. Changed > >> 2. Now tbm_free is not freeing any of the shared members which can be >> accessed by other worker so

Re: [HACKERS] IF (NOT) EXISTS in psql-completion

* David Fetter (da...@fetter.org) wrote: > On Mon, Feb 27, 2017 at 11:53:17PM -0500, Stephen Frost wrote: > > * Kyotaro HORIGUCHI (horiguchi.kyot...@lab.ntt.co.jp) wrote: > > > I suppose it is for suggesting what kind of word should come > > > there, or avoiding silence for a tab. Or for symmetry

Re: [HACKERS] timeouts in PostgresNode::psql

On 02/28/2017 07:39 AM, Alvaro Herrera wrote: > Lately I've been wondering about backpatching the whole TAP test > infrastructure, all the way back. As we notice bugs, it's really useful > to use newly added tests in all branches; but currently PostgresNode > doesn't work with old branches,

Re: [HACKERS] [POC] hash partitioning

Hi, Yugo. Looks like a great feature! I'm going to take a closer look on your code and write a feedback shortly. For now I can only tell that you forgot to include some documentation in the patch. I've added a corresponding entry to current commitfest [1]. Hope you don't mind. If it's not too

Re: [HACKERS] Disallowing multiple queries per PQexec()

On 02/28/2017 03:13 PM, Bruce Momjian wrote: I might have added that one; the text is: Consider disallowing multiple queries in PQexec() as an additional barrier to SQL injection attacks and it is a "consider" item. Should it be moved to the Wire Protocol Changes / v4 Protocol

Re: [HACKERS] btree_gin and btree_gist for enums

On 02/27/2017 04:41 PM, Tom Lane wrote: > Andrew Dunstan writes: >> OK, here's the whole series of patches. > I've not tested it at all, but this looks generally sane in a quick > once-over. > > A minor quibble is that in 0003, you weren't terribly consistent

[HACKERS] [POC] hash partitioning

Hi all, Now we have a declarative partitioning, but hash partitioning is not implemented yet. Attached is a POC patch to add the hash partitioning feature. I know we will need more discussions about the syntax and other specifications before going ahead the project, but I think this runnable code

[HACKERS] Declarative partitioning optimization for large amount of partitions

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 $$

Re: [HACKERS] rename pg_log directory?

On Tue, Feb 28, 2017 at 5:07 AM, Magnus Hagander wrote: > > server_log seems like a better choice then I think. So +1 for that. > ​server_log +1 ​ > > In theory cluster_log since it's a "cluster level log", but given how many > people already get confused by the term

Re: [HACKERS] patch proposal

Hi David, On Tue, Jan 31, 2017 at 6:49 AM, David Steele wrote: > On 1/27/17 3:19 AM, Venkata B Nagothi wrote: > > > I will be adding the tests in > > src/test/recovery/t/003_recovery_targets.pl > > . My tests would look more or less > >

Re: [HACKERS] Disallowing multiple queries per PQexec()

On Tue, Feb 28, 2017 at 09:04:29AM -0500, Tom Lane wrote: > Surafel Temesgen writes: > > This assignment is on todo list and has a benefit of providing an > > additional defense against SQL-injection attacks. > > This is on the todo list? Really? It seems unlikely to be

Re: [HACKERS] Disallowing multiple queries per PQexec()

Surafel Temesgen writes: > This assignment is on todo list and has a benefit of providing an > additional defense against SQL-injection attacks. This is on the todo list? Really? It seems unlikely to be worth the backwards-compatibility breakage. I certainly doubt that

Re: [HACKERS] port of INSTALL file generation to XSLT

On Mon, Feb 27, 2017 at 4:55 PM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 12/31/16 07:33, Magnus Hagander wrote: > > Borka being a standard debian jessie install has Pandoc > > 1.12.4.2~dfsg-1+b14. Should be no problem installing that. > > > > I ran a "make INSTALL" on a

Re: [HACKERS] BRIN de-summarize ranges

Alvaro Herrera writes: > Here's a small patch to make a BRIN page range unsummarized. This is > useful if data has been deleted, and the heap pages are now used for > completely different data. This seems remarkably, um, manual. Why shouldn't users expect the system

[HACKERS] Skip all-visible pages during second HeapScan of CIC

Hello All, During the second heap scan of CREATE INDEX CONCURRENTLY, we're only interested in the tuples which were inserted after the first scan was started. All such tuples can only exists in pages which have their VM bit unset. So I propose the attached patch which consults VM during second

Re: [HACKERS] avoid bloat from CREATE INDEX CONCURRENTLY

Simon Riggs writes: > On 28 February 2017 at 13:05, Tom Lane wrote: >> Um ... isn't there a transaction boundary there anyway? > Yes, the patch releases the snapshot early, so it does not hold it > once the build scan has completed. This allows the

Re: [HACKERS] Other formats in pset like markdown, rst, mediawiki

Current state is something like this (diff is attached). I currently haven`t regression test, tab completion etc., I will add this thing following structure of asciidoc commit. Output is tested using retext, rst is OK, md have problem with cells with newline (i must find out, how it is possible

Re: [HACKERS] avoid bloat from CREATE INDEX CONCURRENTLY

On 28 February 2017 at 13:05, Tom Lane wrote: > Alvaro Herrera writes: >> This patch reduces the amount of bloat you get from running CREATE INDEX >> CONCURRENTLY by destroying the snapshot taken in the first phase, before >> entering the second

[HACKERS] Avoiding bloat in CIC

In CREATE INDEX CONCURRENTLY it seems possible to release the index build snapshot early, so we can reset our xmin before we complete the sort and write the main part of the index. Patch to implement this attached. -- Simon Riggshttp://www.2ndQuadrant.com/ PostgreSQL

Re: [HACKERS] Statement-level rollback

"Tsunakawa, Takayuki" writes: > As I stated here and at the PGConf.ASIA developer meeting last year, I'd > like to propose statement-level rollback feature. I do not really see how this would ever get past the compatibility problems that forced us to give up on

Re: [HACKERS] avoid bloat from CREATE INDEX CONCURRENTLY

Alvaro Herrera writes: > This patch reduces the amount of bloat you get from running CREATE INDEX > CONCURRENTLY by destroying the snapshot taken in the first phase, before > entering the second phase. This allows the global xmin to advance, Um ... isn't there a

[HACKERS] postgres_fdw: evaluate placeholdervars on remote server

Hi, Here is a patch for $subject. This is the same as what I proposed in combination with a feature for full joins [1]; this would allow us to push down left/right/full joins with PHVs to the remote and improve how to deparse whole-row references. Since this is implemented on top of

Re: [HACKERS] timeouts in PostgresNode::psql

Michael Paquier wrote: > On Mon, Feb 27, 2017 at 11:28 AM, Craig Ringer wrote: > > Instead of > > > > $exc_save !~ /^$timeout_exception.*/ > > > > I've updated to: > > > > $exc_save !~ /^\Q$timeout_exception\E/ > > > > i.e. don't do an unnecessary wildcard match at the

Re: [HACKERS] [PATCH] few fts functions for jsonb

The proposed patch looks not very important, but I consider it as an important feature, which Oracle and Microsoft already have, that's why I asked Dmitry to work on this and made it before feature freeze. My comments follows below the post. On Tue, Feb 28, 2017 at 1:59 PM, Dmitry Dolgov

Re: [HACKERS] Enabling parallelism for queries coming from SQL or other PL functions

On Mon, Feb 27, 2017 at 12:21 PM, Robert Haas wrote: > On Mon, Feb 27, 2017 at 8:33 AM, Amit Kapila wrote: >> Is there any easy way to find out which way is less expensive? > > No. But that's a separate problem. I'm just saying we shouldn't >

Re: [HACKERS] Should we cacheline align PGXACT?

Hi, On Fri, Feb 24, 2017 at 12:22 PM, Ashutosh Sharma wrote: On Fri, Feb 24, 2017 at 10:41 AM, Simon Riggs wrote: > > On 24 February 2017 at 04:41, Ashutosh Sharma > wrote: > >> > >> Okay. As suggested by Alexander, I have

Re: [HACKERS] Wrong variable type in KeepLogSeg

On Tue, Feb 28, 2017 at 3:17 AM, Kyotaro HORIGUCHI < horiguchi.kyot...@lab.ntt.co.jp> wrote: > Hello, I found a variable definition with wrong type > specification in KeepLogSeg, which doesn't harm anything. > > > static void > > KeepLogSeg(XLogRecPtr recptr, XLogSegNo *logSegNo) > > { > > ... >

Re: [HACKERS] rename pg_log directory?

On Tue, Feb 28, 2017 at 4:01 AM, Bruce Momjian wrote: > On Mon, Feb 27, 2017 at 09:51:26AM -0500, Tom Lane wrote: > > Peter Eisentraut writes: > > > How about changing the default for log_directory from 'pg_log' to, say, > > > 'log'? > > > > >

  1   2   >