Re: [HACKERS] extension build issue with PostgreSQL 10 on Centos6

2017-09-30 7:54 GMT+02:00 Pavel Stehule : > Hi > > There is new, not well solved dependency. I have not any problem to build > extension with PostgreSQL 9.6 there > > [oracle@ora2pg plpgsql_check]$ make > gcc -Wall -Wmissing-prototypes -Wpointer-arith >

[HACKERS] extension build issue with PostgreSQL 10 on Centos6

Hi There is new, not well solved dependency. I have not any problem to build extension with PostgreSQL 9.6 there [oracle@ora2pg plpgsql_check]$ make gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security

Re: [HACKERS] Why are we including netinet/tcp.h so widely?

Andres Freund writes: > A lot of files which currently include netinet/tcp.h. For most of them I > cannot recognize why, and it just seems to have been copied from one > file to the next. According to POSIX, that supplies TCP_NODELAY, and a look into the file here finds these

Re: [HACKERS] 64-bit queryId?

Robert Haas writes: > How about widening the value to uint64? Doesn't really seem like that would guarantee no collisions. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] SQL/JSON in PostgreSQL

2017-09-30 1:06 GMT+02:00 Nikita Glukhov : > On 29.09.2017 20:07, Pavel Stehule wrote: > > 2017-09-29 12:15 GMT+02:00 Pavel Stehule : > >> >> 2017-09-29 12:09 GMT+02:00 Nikita Glukhov : >> >>> >>> >>> I have some free time

Re: [HACKERS] Parallel Append implementation

On Sat, Sep 30, 2017 at 4:02 AM, Robert Haas wrote: > On Fri, Sep 29, 2017 at 7:48 AM, Amit Kapila wrote: >> I think in general the non-partial paths should be cheaper as compared >> to partial paths as that is the reason planner choose not to make

[HACKERS] 64-bit queryId?

Our Query currently has space for a 32-bit queryId, but that seems reasonably likely to result in collisions: https://en.wikipedia.org/wiki/Birthday_problem#Probability_table If you have as many as 50,000 queries, there's a 25% probability of having at least one collision; that doesn't seem

Re: [HACKERS] CREATE COLLATION does not sanitize ICU's BCP 47 language tags. Should it?

On Mon, Sep 25, 2017 at 11:40 AM, Peter Eisentraut wrote: > Reading over this code again, it is admittedly not quite clear why this > "canonicalization" is in there right now. I think it had something to > do with how we built the keyword variants at one point.

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Wed, Sep 20, 2017 at 2:32 AM, Rushabh Lathia wrote: > Yes, I haven't touched the randomAccess part yet. My initial goal was > to incorporate the BufFileSet api's here. This is going to need a rebase, due to the commit today to remove replacement selection sort. That

[HACKERS] pg_basebackup --progress output for batch execution

Hi, Some time ago I had to work on a system where I was cloning a standby using pg_basebackup, that didn't have screen or tmux. For that reason I redirected the output to a file and ran it with nohup. I normally (always actually ;) ) run pg_basebackup with --progress and --verbose so I can

Re: [HACKERS] SendRowDescriptionMessage() is slow for queries with a lot of columns

On 2017-09-29 17:56:10 -0400, Tom Lane wrote: > Andres Freund writes: > > Does anybody have an opinion on whether we'll want to convert examples > > like testlibpq3.c (included in libpq.sgml) too? I'm inclined not to, > > because currently using pg_bswap.h requires c.h

Re: [HACKERS] User-perspective knowledge about wait events

On Sat, Sep 30, 2017 at 4:20 AM, Schneider wrote: > On Tue, Sep 26, 2017 at 4:28 PM, Michael Paquier > wrote: >> Gathering a set of examples on wiki page with some rough >> analysis I think would be a good start. > > I don't seem to have privs

Re: [HACKERS] Parallel Append implementation

On Fri, Sep 29, 2017 at 7:48 AM, Amit Kapila wrote: > I think in general the non-partial paths should be cheaper as compared > to partial paths as that is the reason planner choose not to make a > partial plan at first place. I think the idea patch is using will help >

[HACKERS] Why are we including netinet/tcp.h so widely?

Hi, A lot of files which currently include netinet/tcp.h. For most of them I cannot recognize why, and it just seems to have been copied from one file to the next. E.g. src/interfaces/libpq/{fe-secure,fe-protocol3,fe-protocol2,fe-secure}.c src/backend/libpq/{be-secure,be-secure-openssl}.c and

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

Hello Robert, ISTM that this bug exists since rate was introduced, so shame on me and back-patching should be needed. I took a look at this and found that the proposed patch applies cleanly all the way back to 9.5, but the regression is reported to have begun with a commit that starts in

[HACKERS] Fwd: Have a problem with citext

Hackers, Are permissions correct in the citext extension? Best, David > Begin forwarded message: > > From: Sadek Touati > Subject: Have a problem with citext > Date: September 29, 2017 at 17:02:50 EDT > To: "da...@kineticode.com" > > Dear

Re: [HACKERS] SendRowDescriptionMessage() is slow for queries with a lot of columns

Andres Freund writes: > Does anybody have an opinion on whether we'll want to convert examples > like testlibpq3.c (included in libpq.sgml) too? I'm inclined not to, > because currently using pg_bswap.h requires c.h presence (just for a few > typedefs and configure data).

Re: [HACKERS] Parallel Append implementation

On Sat, Sep 16, 2017 at 2:15 AM, Amit Kapila wrote: > Yes, we can do that and that is what I think is probably better. So, > the question remains that in which case non-parallel-aware partial > append will be required? Basically, it is not clear to me why after > having

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

On Mon, Sep 11, 2017 at 4:49 AM, Fabien COELHO wrote: > 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 >

Re: [HACKERS] SendRowDescriptionMessage() is slow for queries with a lot of columns

On 2017-09-28 14:23:45 +0900, Michael Paquier wrote: > On Thu, Sep 28, 2017 at 1:31 PM, Andres Freund wrote: > > On September 27, 2017 9:06:49 PM PDT, Andres Freund > > wrote: > >>On 2017-09-28 00:01:53 -0400, Tom Lane wrote: > >>> Could we please not

Re: [HACKERS] alter server for foreign table

On Fri, Sep 29, 2017 at 10:19:03PM +0200, David Fetter wrote: > On Fri, Sep 29, 2017 at 01:47:59PM -0400, Tom Lane wrote: > > Konstantin Knizhnik writes: > > > According to Postgresql documentation it is not possible to alter server > > > for foreign table: > > >

Re: [HACKERS] Shaky coding for vacuuming partitioned relations

Robert Haas writes: > On Fri, Sep 29, 2017 at 12:43 PM, Tom Lane wrote: >> Robert Haas writes: >>> If I understand correctly, problem #1 is that get_rel_oids() can emit >>> a user-visible cache lookup failure message. There is a

Re: [HACKERS] pg_prepared_xact_status

On Fri, Sep 29, 2017 at 4:22 AM, Craig Ringer wrote: > This sounds kind-of like 1/4 of a distributed transaction resolver, without > a way to make it reliable enough to build the other 3/4. > > To make this practical I think you'd need a way to retain historic GIDs + >

Re: [HACKERS] alter server for foreign table

On Fri, Sep 29, 2017 at 01:47:59PM -0400, Tom Lane wrote: > Konstantin Knizhnik writes: > > According to Postgresql documentation it is not possible to alter server > > for foreign table: > > https://www.postgresql.org/docs/10/static/sql-alterforeigntable.html > >

Re: [HACKERS] Arrays of domains

On 09/29/2017 01:10 PM, Tom Lane wrote: > Andrew Dunstan writes: >> On 09/28/2017 05:44 PM, Tom Lane wrote: >>> Assuming that that's going to happen for v11, I'm inclined to leave the >>> optimization problem until the dust settles around CaseTestExpr. >>> Does

Re: [HACKERS] Partitions: \d vs \d+

On Thu, Sep 28, 2017 at 9:33 PM, Amit Langote wrote: > Perhaps, there is no case when "No partition constraint" should be output, > but I may be missing something. The case arises when a partitioned table has a default partition but no other partitions. I have

Re: [HACKERS] UPDATE of partition key

On Fri, Sep 22, 2017 at 1:57 AM, Amit Khandekar wrote: > The patch for the above change is : > 0002-Prevent-a-redundant-ConvertRowtypeExpr-node.patch Thinking about this a little more, I'm wondering about how this case arises. I think that for this patch to avoid

Re: [HACKERS] Multicolumn hash indexes

On Fri, Sep 29, 2017 at 10:54:55AM -0400, Tom Lane wrote: > There are few if any indexing techniques where the first column isn't > significantly more important than the rest --- certainly that's true > for btree, for example. I do not think it's a showstopper if that's > true for hash as well.

Re: [HACKERS] User-perspective knowledge about wait events

On Tue, Sep 26, 2017 at 4:28 PM, Michael Paquier wrote: > Gathering a set of examples on wiki page with some rough > analysis I think would be a good start. I don't seem to have privs to create wiki pages; can someone else make a page where we can begin to gather

Re: [HACKERS] pgbench stuck with 100% cpu usage

On Thu, Sep 28, 2017 at 10:36 PM, Pavan Deolasee wrote: > Well, I think it's a very legitimate test, not for testing performance, but > testing crash recovery and I use it very often. This particular test was run > to catch another bug which will be reported separately.

Re: [HACKERS] pgbench stuck with 100% cpu usage

Committed and back-patched to v10. I have to say I'm kind of surprised that the comment removed by this patch got committed in the first place. It's got a ??? in it and isn't very grammatical either. ISTM that I reviewed the initial patch. AFAICR I agreed with the comment that whether it

Re: [HACKERS] [PATCH]make pg_rewind to not copy useless WAL files

On Fri, Sep 29, 2017 at 8:10 PM, chenhj wrote: > On 2017-09-30 00:53:31，"chenhj" wrote: > > On 2017-09-29 19:29:40，"Alexander Korotkov" > wrote: > > On Fri, Sep 29, 2017 at 10:07 AM, chenhj wrote: >> >> >> > OK.

Re: [HACKERS] Multicolumn hash indexes

On Fri, Sep 29, 2017 at 6:33 PM, Robert Haas wrote: > Now you could also imagine something where we keep a separate set of > hash buckets for each column and multi-column searches are handled by > searching each hash table separately and taking the intersection of > the

[HACKERS] Re: COMMIT TRIGGERs, take n+1

The attached file demonstrates how to create COMMIT, BEGIN, and even session CONNECT TRIGGERs for PostgreSQL using PlPgSQL only, via normal and CONSTRAINT TRIGGERs. There have been many threads on the PG mailing lists about commit triggers, with much skepticism shown about the possible semantics

Re: [HACKERS] A design for amcheck heapam verification

On Fri, Sep 29, 2017 at 1:57 PM, Peter Geoghegan wrote: > On Fri, Sep 29, 2017 at 10:29 AM, Robert Haas wrote: >> I am also wondering whether this patch should consider >> 81c5e46c490e2426db243eada186995da5bb0ba7 as a way of obtaining >> multiple hash values.

Re: [HACKERS] pgbench stuck with 100% cpu usage

On Fri, Sep 29, 2017 at 1:39 AM, Pavan Deolasee wrote: > Looks good to me. Committed and back-patched to v10. I have to say I'm kind of surprised that the comment removed by this patch got committed in the first place. It's got a ??? in it and isn't very grammatical

Re: [HACKERS] A design for amcheck heapam verification

On Fri, Sep 29, 2017 at 10:29 AM, Robert Haas wrote: > I am also wondering whether this patch should consider > 81c5e46c490e2426db243eada186995da5bb0ba7 as a way of obtaining > multiple hash values. I suppose that's probably inferior to what is > already being done on

Re: [HACKERS] A design for amcheck heapam verification

On Thu, Sep 28, 2017 at 8:34 PM, Thomas Munro wrote: > FWIW I think if I were attacking that problem the first thing I'd > probably try would be getting rid of that internal pointer > filter->bitset in favour of a FLEXIBLE_ARRAY_MEMBER and then making > the

Re: [HACKERS] psql \d sequence display

On 9/25/17 13:53, Fabien COELHO wrote: > \d+ does not show more. > > Maybe Type, Min, Max, Inc & Cycles are enough for \d? That seems kind of arbitrary. Start and Cache are just as relevant. > The next/future or last/previous value is not shown. If one could be > available it would be nice to

Re: [HACKERS] alter server for foreign table

Konstantin Knizhnik writes: > According to Postgresql documentation it is not possible to alter server > for foreign table: > https://www.postgresql.org/docs/10/static/sql-alterforeigntable.html Hmm, we'd have to check if the table's options were legal for the new

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

reality. So I don't know if this needs backpatching or not. But it should be fixed for v10, as there it becomes a demonstrably live issue. Yes. -- Fabien. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] Bug with pg_basebackup and 'shared' tablespace

On Fri, Sep 29, 2017 at 2:06 AM, Michael Paquier wrote: > My tendency about this patch is still that it should be rejected. This > is presenting additional handling for no real gain. I vehemently disagree. If the server lets you create a tablespace, then everything

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

On Fri, Sep 29, 2017 at 12:44 AM, Vaishnavi Prabakaran wrote: > Option name "--enable-pgdumpall-behaviour" is very generic Yeah, that's a terrible name, at least in my opinion. > and it is better > to rename it to something that reflects its functionality like >

Re: [HACKERS] A design for amcheck heapam verification

On Thu, Sep 28, 2017 at 11:34 PM, Thomas Munro wrote: > FWIW I think if I were attacking that problem the first thing I'd > probably try would be getting rid of that internal pointer > filter->bitset in favour of a FLEXIBLE_ARRAY_MEMBER and then making > the

Re: [HACKERS] [PATCH]make pg_rewind to not copy useless WAL files

On 2017-09-30 00:53:31，"chenhj" wrote: On 2017-09-29 19:29:40，"Alexander Korotkov" wrote: On Fri, Sep 29, 2017 at 10:07 AM, chenhj wrote: OK. That makes sense. Thank you for the explanation. I still have some minor

Re: [HACKERS] Arrays of domains

Andrew Dunstan writes: > On 09/28/2017 05:44 PM, Tom Lane wrote: >> Assuming that that's going to happen for v11, I'm inclined to leave the >> optimization problem until the dust settles around CaseTestExpr. >> Does anyone feel that this can't be committed before

Re: [HACKERS] SQL/JSON in PostgreSQL

2017-09-29 12:15 GMT+02:00 Pavel Stehule : > > > 2017-09-29 12:09 GMT+02:00 Nikita Glukhov : > >> >> >> I have some free time now. Is it last version? >> >> Regards >> >> Pavel >> >> Yes, this is still the latest version. Now I am working only on

[HACKERS] alter server for foreign table

According to Postgresql documentation it is not possible to alter server for foreign table: https://www.postgresql.org/docs/10/static/sql-alterforeigntable.html But stackoverflow suggests the following hack directly updating |pg_foreign_table|:

Re: [HACKERS] SendRowDescriptionMessage() is slow for queries with a lot of columns

On Fri, Sep 29, 2017 at 5:02 AM, tushar wrote: > Case 3- TIME=1000 > > PG HEAD =>tps = 1061.031463 (excluding connections establishing) > PG HEAD+patch => tps= 8011.784839(3.30+% vs. head) Going from 1061 tps to 8011 tps is not a 3.3% gain. I assume you garbled

Re: [HACKERS] [POC] hash partitioning

On Thu, Sep 28, 2017 at 1:54 AM, Amit Langote wrote: > I looked into how satisfies_hash_partition() works and came up with an > idea that I think will make constraint exclusion work. What if we emitted > the hash partition constraint in the following form instead:

Re: [HACKERS] [PATCH]make pg_rewind to not copy useless WAL files

On 2017-09-29 19:29:40，"Alexander Korotkov" wrote: On Fri, Sep 29, 2017 at 10:07 AM, chenhj wrote: OK. That makes sense. Thank you for the explanation. I still have some minor comments. /* +* Save the WAL filenames of the divergence

Re: [HACKERS] Shaky coding for vacuuming partitioned relations

On Fri, Sep 29, 2017 at 12:43 PM, Tom Lane wrote: > Robert Haas writes: >> If I understand correctly, problem #1 is that get_rel_oids() can emit >> a user-visible cache lookup failure message. There is a proposed patch >> by Michael Paquier which

Re: [HACKERS] Shaky coding for vacuuming partitioned relations

Robert Haas writes: > If I understand correctly, problem #1 is that get_rel_oids() can emit > a user-visible cache lookup failure message. There is a proposed patch > by Michael Paquier which appears to implement the design suggested by > Tom. I think that the normal

Re: [HACKERS] path toward faster partition pruning

On Thu, Sep 28, 2017 at 5:16 AM, David Rowley wrote: > I'd imagine, for > each partition key, you'd want to store a Datum with the minimum and > maximum possible value based on the quals processed. If either the > minimum or maximum is still set to NULL, then it's

Re: [HACKERS] Shaky coding for vacuuming partitioned relations

On 9/29/17, 11:18 AM, "Robert Haas" wrote: > I don't think I understand problem #2. I think the concern is about > reporting the proper relation name when VACUUM cascades from a > partitioned table to its children and then some kind of concurrent DDL > happens, but I don't

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

On Mon, Sep 11, 2017 at 6:27 PM, Fabien COELHO wrote: > > 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

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

On Fri, Sep 29, 2017 at 7:19 AM, Robert Haas wrote: > That supports your theory that there's some confounding factor in the > CREATE INDEX case, such as I/O scheduling. Since this machine has an > SSD, I guess I don't have a mental model for how that works. We're > not

Re: [HACKERS] Shaky coding for vacuuming partitioned relations

On Thu, Sep 28, 2017 at 1:31 AM, Noah Misch wrote: > This thread now has two open items, both of them pertaining to VACUUM error > messages involving partitioning. The pair is probably best treated as a > single open item. If I understand correctly, problem #1 is that

Re: [HACKERS] list of credits for release notes

On 9/29/17 11:35, Robert Haas wrote: > On Wed, Sep 27, 2017 at 8:29 PM, Michael Paquier > wrote: >> Looking at this list, the first name is followed by the family name, >> so there are inconsistencies with some Japanese names: >> - Fujii Masao should be Masao Fujii. >>

Re: [HACKERS] Transactions involving multiple postgres foreign servers

On Wed, Sep 27, 2017 at 11:15 PM, Masahiko Sawada wrote: > I think that making a resolver process have connection caches to each > foreign server for a while can reduce the overhead of connection to > foreign servers. These connections will be invalidated by DDLs. Also, >

Re: [HACKERS] list of credits for release notes

On Wed, Sep 27, 2017 at 8:29 PM, Michael Paquier wrote: > Looking at this list, the first name is followed by the family name, > so there are inconsistencies with some Japanese names: > - Fujii Masao should be Masao Fujii. > - KaiGai Kohei should be Kohei Kaigai. But

Re: [HACKERS] Multicolumn hash indexes

On Fri, Sep 29, 2017 at 10:54 AM, Tom Lane wrote: > There are few if any indexing techniques where the first column isn't > significantly more important than the rest --- certainly that's true > for btree, for example. Well, BRIN doesn't care. > I do not think it's a

Re: bgw_type (was Re: [HACKERS] Why does logical replication launcher set application_name?)

On 9/27/17 18:59, Daniel Gustafsson wrote: > The patch applies with minor fuzz, compiles without introduced warnings and > work the way it says on the tin. The utility of the proposed functionality is > a clear win so +1 on getting that in. I have committed this patch incorporating the feedback

Re: bgw_type (was Re: [HACKERS] Why does logical replication launcher set application_name?)

On 8/31/17 23:22, Michael Paquier wrote: > On Fri, Sep 1, 2017 at 4:49 AM, Peter Eisentraut > wrote: >> On 5/30/17 23:10, Peter Eisentraut wrote: >>> Here is a proposed solution that splits bgw_name into bgw_type and >>> bgw_name_extra. bgw_type shows up in

Re: [HACKERS] Multicolumn hash indexes

Robert Haas writes: > Maybe you're worrying about something like a billion-row table where > there are 3 columns that form a composite key: (1,1,1), (1,1,2), ..., > (1,1000),(1,2,1),...,(1,1000,1000),(2,1,1),...,(1000,1000,1000). In > that case, treating the leading column

Re: [HACKERS] GSoC 2017: weekly progress reports (week 4) and patch for hash index

On Fri, Sep 8, 2017 at 4:07 AM, Thomas Munro wrote: > Hi Shubham, > > On Tue, Jun 27, 2017 at 9:21 PM, Shubham Barai > wrote: > > If these two hash keys (78988658 and 546789888) mapped to the same > bucket, this will result in false

Re: [HACKERS] Multicolumn hash indexes

On Wed, Sep 27, 2017 at 5:52 PM, Tomasz Ostrowski wrote: > I feel that this would eliminate a large amount of potential gains from such > an index. This would be usable only when a sufficiently variable column > exists, in which case a simple hash index on the column

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

On Thu, Sep 28, 2017 at 6:44 PM, Peter Geoghegan wrote: > I'm glad to hear that. But, I should reiterate that if sorting > actually gets faster when my patch is applied, then that's something > that I consider to be a bonus. (This is primarily a refactoring patch, > to remove a

Re: [HACKERS] plpgsql_check future

Hello Pavel, 1. It is placed on my personal repository on GitHub. It is far to perfect from security, from substitutability perspective. Any ideas? Ask to have a copy on git.postgresql.org? -- Fabien. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes

Re: [HACKERS] Fix bloom WAL tap test

On Wed, Sep 6, 2017 at 5:06 PM, Alexander Korotkov < a.korot...@postgrespro.ru> wrote: > On Wed, Sep 6, 2017 at 4:08 PM, Alexander Korotkov < > a.korot...@postgrespro.ru> wrote: > >> I just realized that these lines of contrib/bloom/t/001_wal.pl don't >> check that queries give same results on

Re: [HACKERS] Enhancements to passwordcheck

On Fri, Sep 29, 2017 at 3:17 PM, Alvaro Herrera wrote: > Michael Paquier wrote: > > > Client commands may be run on a trusted network as well, let's not > > forget that. > > I've never seen this "trusted network" thing of which you speak. Is it > nice? > I believe it's

Re: [HACKERS] Arrays of domains

On 09/28/2017 05:44 PM, Tom Lane wrote: > > I get these query timings in a non-cassert build: > > HEADPatch > > Q15453.235 ms 5440.876 ms > Q29340.670 ms 10191.194 ms > Q319078.457 ms18967.279 ms > Q448196.338 ms58547.531 ms > > [ analysis

Re: [HACKERS] Enhancements to passwordcheck

Michael Paquier wrote: > Client commands may be run on a trusted network as well, let's not > forget that. I've never seen this "trusted network" thing of which you speak. Is it nice? -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote

Re: [HACKERS] Patch: add --if-exists to pg_recvlogical

On 9/22/17 15:31, Peter Eisentraut wrote: > I suggest you create a patch that focuses on the --create part. > > You can create a separate follow-on patch for the --start part if you > wish, but I think that that patch would be rejected. I have moved this entry to the next commit fest, awaiting

Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test

On 9/22/17 16:48, Peter Eisentraut wrote: > On 9/19/17 19:00, Michael Paquier wrote: >> On Wed, Sep 20, 2017 at 7:57 AM, Peter Eisentraut >> wrote: >>> To get things rolling, I have committed just the basic TAP tests, to >>> give it a spin on the build farm.

Re: [HACKERS] Walsender timeouts and large transactions

Good day, Kyoutaro On 2017-09-29 11:26, Kyotaro HORIGUCHI wrote: Hello, At Wed, 27 Sep 2017 14:28:37 +0300, Sokolov Yura wrote in <90bb67da7131e6186b50897c4b0f0...@postgrespro.ru> On 2017-09-12 11:28, Kyotaro HORIGUCHI wrote: > Hello, > At Wed, 06 Sep 2017

Re: [HACKERS] Parallel Append implementation

On Wed, Sep 20, 2017 at 10:59 AM, Amit Khandekar wrote: > On 16 September 2017 at 10:42, Amit Kapila wrote: >> On Thu, Sep 14, 2017 at 9:41 PM, Robert Haas wrote: >>> On Mon, Sep 11, 2017 at 9:25 AM, Amit Kapila

Re: [HACKERS] [PATCH]make pg_rewind to not copy useless WAL files

On Fri, Sep 29, 2017 at 10:07 AM, chenhj wrote: > On 2017-09-29 05:31:51, "Alexander Korotkov" > wrote: > > On Thu, Sep 28, 2017 at 10:52 PM, chenhj wrote: > >> On 2017-09-29 00:43:18，"Alexander Korotkov"

Re: [HACKERS] SQL/JSON in PostgreSQL

2017-09-29 12:09 GMT+02:00 Nikita Glukhov : > > > I have some free time now. Is it last version? > > Regards > > Pavel > > Yes, this is still the latest version. Now I am working only on unfinished > WIP > patch no. 9, but I think it should be reviewed the last. > > ok

Re: [HACKERS] SQL/JSON in PostgreSQL

On 29.09.2017 12:59, Pavel Stehule wrote: Hi 2017-09-16 1:31 GMT+02:00 Nikita Glukhov >: On 15.09.2017 22:36, Oleg Bartunov wrote: On Fri, Sep 15, 2017 at 7:31 PM, Robert Haas

Re: [HACKERS] SQL/JSON in PostgreSQL

Hi 2017-09-16 1:31 GMT+02:00 Nikita Glukhov : > On 15.09.2017 22:36, Oleg Bartunov wrote: > > On Fri, Sep 15, 2017 at 7:31 PM, Robert Haas >> wrote: >> >>> On Fri, Sep 15, 2017 at 10:10 AM, Daniel Gustafsson >>> wrote: >>>

Re: [HACKERS] pg_prepared_xact_status

On 29.09.2017 11:27, Craig Ringer wrote: On 29 September 2017 at 15:57, Konstantin Knizhnik > wrote: So you are saying that Postgresql 2PC mechanism is not complete and user needs to maintain some extra information to make

Re: [HACKERS] Partitions: \d vs \d+

On 29.09.2017 04:33, Amit Langote wrote: So, we should be looking at partconstraintdef only when verbose is true, because that's only when we set it to a valid value. Now, if partconstraintdef is NULL even after verbose is true, that means backend returned that there exists no constraint for

Re: [HACKERS] SendRowDescriptionMessage() is slow for queries with a lot of columns

On 09/27/2017 10:50 PM, Andres Freund wrote: This'll allow the later patches to allow the compiler to perform the relevant optimizations. It also allows to optimize e.g. pq_sendint64() to avoid having to do multiple byteswaps. After applying all the required patches, able to see some

Re: [HACKERS] pg_prepared_xact_status

On 29 September 2017 at 15:57, Konstantin Knizhnik < k.knizh...@postgrespro.ru> wrote: > So you are saying that Postgresql 2PC mechanism is not complete and user > needs to maintain some extra information to make it work? > No, it provides what's needed for an implementation of what in XA terms

Re: [HACKERS] Walsender timeouts and large transactions

Hello, At Wed, 27 Sep 2017 14:28:37 +0300, Sokolov Yura wrote in <90bb67da7131e6186b50897c4b0f0...@postgrespro.ru> > On 2017-09-12 11:28, Kyotaro HORIGUCHI wrote: > > Hello, > > At Wed, 06 Sep 2017 13:46:16 +, Yura Sokolov > > wrote

Re: [HACKERS] pg_prepared_xact_status

On 29 September 2017 at 15:57, Konstantin Knizhnik < k.knizh...@postgrespro.ru> wrote: > > The idea of pg_prepared_xact_status function is that it allows to get > status of 2PC transaction without any additional requirements to GIDs and > any other additional information about participants of 2PC

Re: [HACKERS] Index expression syntax

On 29.09.2017 11:03, Marko Tiikkaja wrote: On Fri, Sep 29, 2017 at 9:31 AM, Konstantin Knizhnik > wrote: I wonder why syntax error is produced in this case: postgres=# create index metaindex on foo using

Re: [HACKERS] Index expression syntax

On Fri, Sep 29, 2017 at 9:31 AM, Konstantin Knizhnik < k.knizh...@postgrespro.ru> wrote: > I wonder why syntax error is produced in this case: > > postgres=# create index metaindex on foo using gin(to_tsvector('english', > x)||to_tsvector('english',y)); > ERROR: syntax error at or near "||" >

Re: [HACKERS] pg_prepared_xact_status

On 29.09.2017 06:02, Michael Paquier wrote: On Fri, Sep 29, 2017 at 1:53 AM, Konstantin Knizhnik wrote: In Postgres 10 we have txid_status function which returns status of transaction by XID. I wonder if it will be also useful to have similar function for 2PC

[HACKERS] Index expression syntax

I wonder why syntax error is produced in this case: postgres=# create index metaindex on foo using gin(to_tsvector('english', x)||to_tsvector('english',y)); ERROR: syntax error at or near "||" LINE 1: ...taindex on foo using gin(to_tsvector('english', x)||to_tsvec...

Re: [HACKERS] UPDATE of partition key

On Wed, Sep 13, 2017 at 4:24 PM, amul sul wrote: > > > On Sun, Sep 10, 2017 at 8:47 AM, Amit Kapila > wrote: >> >> On Fri, Sep 8, 2017 at 4:51 PM, amul sul wrote: >> > On Thu, May 18, 2017 at 9:13 AM, Amit Kapila

Re: [HACKERS] [PATCH]make pg_rewind to not copy useless WAL files

On 2017-09-29 05:31:51, "Alexander Korotkov" wrote: On Thu, Sep 28, 2017 at 10:52 PM, chenhj wrote: On 2017-09-29 00:43:18，"Alexander Korotkov" wrote: On Thu, Sep 28, 2017 at 6:44 PM, chenhj wrote: On

Re: [HACKERS] Enhancements to passwordcheck

Michael Paquier wrote: > On Thu, Sep 28, 2017 at 12:06 AM, Alvaro Herrera > wrote: >> I think the passwordcheck module as a whole is a dead end, security- >> wise. Myself, I've never seen the point in it. It runs at the wrong >> time, and there's no way to fix that. >

Re: [HACKERS] pgbench stuck with 100% cpu usage

- Run pgbench -c 10 -T 100 - Stop postgres with -m immediate That is a strange test to run, but it would be better if the behavior was not that one. Well, I think it's a very legitimate test, not for testing performance, but testing crash recovery and I use it very often. Ok,

Re: [HACKERS] Bug with pg_basebackup and 'shared' tablespace

On Fri, Sep 29, 2017 at 2:19 PM, Kyotaro HORIGUCHI wrote: > It would practically work but I don't like the fact that the > patch relies on the specific directory/file ordering in the tar > stream. This is not about the CATVER directory but lower > directories.

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

On Fri, Sep 29, 2017 at 6:39 AM, Alvaro Herrera wrote: > Peter Geoghegan wrote: > >> We certainly do still see wrong answers to queries here: >> >> postgres=# select ctid, xmin, xmax, * from t; >> ctid | xmin | xmax | id | name | x >>