Re: [HACKERS] Missing XLOG_DEBUG check in AdvanceXLInsertBuffer()?

2015-06-10 Thread Michael Paquier
On Wed, Jun 10, 2015 at 8:02 PM, Andres Freund and...@anarazel.de wrote: Does somebody mind me backpatching the missing XLOG_DEBUG ? ISTM that it is a good idea to have it in REL9_4_STABLE as well. Regards, -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To

[HACKERS] comment doesn't match code

2015-06-10 Thread Robert Haas
/* * ALTER TABLE INHERIT * * Add a parent to the child's parents. This verifies that all the columns and * check constraints of the parent appear in the child and that they have the * same data types and expressions. */ static void ATPrepAddInherit(Relation child_rel) { if

[HACKERS] Missing XLOG_DEBUG check in AdvanceXLInsertBuffer()?

2015-06-10 Thread Andres Freund
Hi, When compiling with WAL_DEBUG defined, but wal_debug set to off, there's a lot of DEBUG1 spew like DEBUG: initialized 1 pages, upto 40/3977E000 DEBUG: initialized 9 pages, upto 40/3979 DEBUG: initialized 1 pages, upto 40/39792000 DEBUG: initialized 1 pages, upto 40/39794000 DEBUG:

Re: [HACKERS] [idea] table partition + hash join

2015-06-10 Thread Kouhei Kaigai
On 2015-06-10 PM 01:42, Kouhei Kaigai wrote: Let's assume a table which is partitioned to four portions, and individual child relations have constraint by hash-value of its ID field. tbl_parent + tbl_child_0 ... CHECK(hash_func(id) % 4 = 0) + tbl_child_1 ...

Re: [HACKERS] Restore-reliability mode

2015-06-10 Thread Andres Freund
On 2015-06-10 01:57:22 -0400, Noah Misch wrote: I think I agree with everything after your first sentence. I liked your specific proposal to split StartupXLOG(), but making broad-appeal restructuring proposals is hard. I doubt we would get good results by casting a wide net for restructuring

Re: [HACKERS] [idea] table partition + hash join

2015-06-10 Thread Atri Sharma
On Wed, Jun 10, 2015 at 2:16 PM, Amit Langote langote_amit...@lab.ntt.co.jp wrote: Perhaps the qual needs to be pushed all the way down to the Hash's underlying scan if that makes sense. And that is a Pandora's box of troubles IMHO unless done in a very careful manner.

Re: [HACKERS] Why no jsonb_exists_path()?

2015-06-10 Thread Alexander Korotkov
Josh, On Tue, Jun 9, 2015 at 9:16 PM, Josh Berkus j...@agliodbs.com wrote: Dmitry, Alexander: I'm noticing a feature gap for JSONB operators; we have no way to do this: jsonb_col ? ARRAY['key1','key2','key3'] What documents do you expect to match this operator? Such syntax can be

Re: [HACKERS] [idea] table partition + hash join

2015-06-10 Thread Amit Langote
On Wed, Jun 10, 2015 at 8:33 PM, Kouhei Kaigai kai...@ak.jp.nec.com wrote: On 2015-06-10 PM 01:42, Kouhei Kaigai wrote: Let's assume a table which is partitioned to four portions, and individual child relations have constraint by hash-value of its ID field. tbl_parent +

[HACKERS] s_lock() seems too aggressive for machines with many sockets

2015-06-10 Thread Jan Wieck
Hi, I think I may have found one of the problems, PostgreSQL has on machines with many NUMA nodes. I am not yet sure what exactly happens on the NUMA bus, but there seems to be a tipping point at which the spinlock concurrency wreaks havoc and the performance of the database collapses. On a

[HACKERS] Auto-vacuum is not running in 9.1.12

2015-06-10 Thread Prakash Itnal
Hello, Recently we encountered a issue where the disc space is continuously increasing towards 100%. Then a manual vacuum freed the disc space. But again it is increasing. When digged more it is found that auto-vacuuming was not running or it is either stucked/hanged. Version: 9.1.12 Auto vacuum

Re: [HACKERS] pg_archivecleanup bug (invalid filename input)

2015-06-10 Thread Michael Paquier
On Wed, Jun 10, 2015 at 12:29 PM, Joshua D. Drake j...@commandprompt.com wrote: On 06/09/2015 05:54 PM, Michael Paquier wrote: Looking at the documentation what is expected is not a path to a segment file, but only a segment file name:

Re: [HACKERS] Checkpoints vs restartpoints

2015-06-10 Thread Andres Freund
On 2015-06-10 11:20:19 +1200, Thomas Munro wrote: I was wondering about this in the context of the recent multixact work, since such configurations could leave you with different SLRU files on disk which in some versions might change the behaviour in interesting ways. Note that trigger a

Re: [HACKERS] Re: [COMMITTERS] pgsql: Map basebackup tablespaces using a tablespace_map file

2015-06-10 Thread Amit Kapila
On Tue, Jun 9, 2015 at 8:37 PM, Andrew Dunstan and...@dunslane.net wrote: On 06/08/2015 11:19 PM, Amit Kapila wrote: I think Robert and Alvaro also seems to be inclined towards throwing error for such a case, so let us do that way, but one small point is that don't you think that similar

Re: [HACKERS] [idea] table partition + hash join

2015-06-10 Thread Amit Langote
On 2015-06-10 PM 05:53, Atri Sharma wrote: On Wed, Jun 10, 2015 at 2:16 PM, Amit Langote langote_amit...@lab.ntt.co.jp wrote: Perhaps the qual needs to be pushed all the way down to the Hash's underlying scan if that makes sense. And that is a Pandora's box of troubles IMHO unless done

Re: [HACKERS] [idea] table partition + hash join

2015-06-10 Thread Amit Langote
On 2015-06-10 PM 01:42, Kouhei Kaigai wrote: Let's assume a table which is partitioned to four portions, and individual child relations have constraint by hash-value of its ID field. tbl_parent + tbl_child_0 ... CHECK(hash_func(id) % 4 = 0) + tbl_child_1 ... CHECK(hash_func(id) %

Re: [HACKERS] s_lock() seems too aggressive for machines with many sockets

2015-06-10 Thread Jan Wieck
On 06/10/2015 09:28 AM, Andres Freund wrote: On 2015-06-10 09:18:56 -0400, Jan Wieck wrote: On a machine with 8 sockets, 64 cores, Hyperthreaded 128 threads total, a pgbench -S peaks with 50-60 clients around 85,000 TPS. The throughput then takes a very sharp dive and reaches around 20,000 TPS

Re: [HACKERS] could not adopt C locale failure at startup on Windows

2015-06-10 Thread Tom Lane
Noah Misch n...@leadboat.com writes: On Tue, Jun 09, 2015 at 12:24:02PM -0400, Tom Lane wrote: Yeah, my first instinct was to blame ca325941 as well, but I don't think any of that code executes during init_locale(). Also,

Re: [HACKERS] reaper should restart archiver even on standby

2015-06-10 Thread Alvaro Herrera
Fujii Masao wrote: On Tue, Jun 9, 2015 at 5:21 AM, Alvaro Herrera alvhe...@2ndquadrant.com wrote: Fujii Masao wrote: Can't we create some common function that would be called both here and on ServerLoop? Agreed. So, what about the attached patch? No attachment ... We also have

Re: [HACKERS] s_lock() seems too aggressive for machines with many sockets

2015-06-10 Thread Nils Goroll
On 10/06/15 16:05, Andres Freund wrote: it'll nearly always be beneficial to spin Trouble is that postgres cannot know if the process holding the lock actually does run, so if it doesn't, all we're doing is burn cycles and make the problem worse. Contrary to that, the kernel does know, so for

Re: [HACKERS] s_lock() seems too aggressive for machines with many sockets

2015-06-10 Thread Jan Wieck
On 06/10/2015 10:07 AM, Nils Goroll wrote: On larger Linux machines, we have been running with spin locks replaced by generic posix mutexes for years now. I personally haven't look at the code for ages, but we maintain a patch which pretty much does the same thing still: Ref:

Re: [HACKERS] s_lock() seems too aggressive for machines with many sockets

2015-06-10 Thread Tom Lane
Jan Wieck j...@wi3ck.info writes: The attached patch demonstrates that less aggressive spinning and (much) more often delaying improves the performance on this type of machine. Hm. One thing worth asking is why the code didn't converge to a good value of spins_per_delay without help. The

Re: [HACKERS] s_lock() seems too aggressive for machines with many sockets

2015-06-10 Thread Andres Freund
On 2015-06-10 16:12:05 +0200, Nils Goroll wrote: On 10/06/15 16:05, Andres Freund wrote: it'll nearly always be beneficial to spin Trouble is that postgres cannot know if the process holding the lock actually does run, so if it doesn't, all we're doing is burn cycles and make the problem

Re: [HACKERS] s_lock() seems too aggressive for machines with many sockets

2015-06-10 Thread Tom Lane
Andres Freund and...@anarazel.de writes: Unfortunately there's no portable futex support. That's what stopped us from adopting them so far. And even futexes can be significantly more heavyweight under moderate contention than our spinlocks - It's rather easy to reproduce scenarios where

Re: [HACKERS] s_lock() seems too aggressive for machines with many sockets

2015-06-10 Thread Bruce Momjian
On Wed, Jun 10, 2015 at 09:18:56AM -0400, Jan Wieck wrote: The attached patch demonstrates that less aggressive spinning and (much) more often delaying improves the performance on this type of machine. The 8 socket machine in question scales to over 350,000 TPS. The patch is meant to

Re: [HACKERS] [COMMITTERS] pgsql: Add pg_audit, an auditing extension

2015-06-10 Thread Noah Misch
On Tue, Jun 09, 2015 at 03:54:59PM -0400, David Steele wrote: I've certainly had quite the experience as a first-time contributor working on this patch. Perhaps I bit off more than I should have and I definitely managed to ruffle a few feathers along the way. I learned a lot about how the

Re: [HACKERS] s_lock() seems too aggressive for machines with many sockets

2015-06-10 Thread Andres Freund
Hi, On 2015-06-10 09:54:00 -0400, Jan Wieck wrote: model name : Intel(R) Xeon(R) CPU E7- 8830 @ 2.13GHz numactl --hardware shows the distance to the attached memory as 10, the distance to every other node as 21. I interpret that as the machine having one NUMA bus with all cpu packages

Re: [HACKERS] s_lock() seems too aggressive for machines with many sockets

2015-06-10 Thread Andres Freund
On 2015-06-10 09:18:56 -0400, Jan Wieck wrote: On a machine with 8 sockets, 64 cores, Hyperthreaded 128 threads total, a pgbench -S peaks with 50-60 clients around 85,000 TPS. The throughput then takes a very sharp dive and reaches around 20,000 TPS at 120 clients. It never recovers from

Re: [HACKERS] The Future of Aggregation

2015-06-10 Thread Kevin Grittner
David Rowley david.row...@2ndquadrant.com wrote: On 10 June 2015 at 02:52, Kevin Grittner kgri...@ymail.com wrote: David Rowley david.row...@2ndquadrant.com wrote: The idea I discussed in the link in item 5 above gets around this problem, but it's a perhaps more surprise filled implementation

Re: [HACKERS] s_lock() seems too aggressive for machines with many sockets

2015-06-10 Thread Nils Goroll
On larger Linux machines, we have been running with spin locks replaced by generic posix mutexes for years now. I personally haven't look at the code for ages, but we maintain a patch which pretty much does the same thing still: Ref:

Re: [HACKERS] Information of pg_stat_ssl visible to all users

2015-06-10 Thread Magnus Hagander
On Tue, Jun 9, 2015 at 10:55 PM, Michael Paquier michael.paqu...@gmail.com wrote: On Tue, Jun 9, 2015 at 3:27 PM, Magnus Hagander mag...@hagander.net wrote: On Jun 9, 2015 6:00 AM, Michael Paquier michael.paqu...@gmail.com wrote: Hi all, I should have noticed that before, but it

Re: [HACKERS] reaper should restart archiver even on standby

2015-06-10 Thread Fujii Masao
On Tue, Jun 9, 2015 at 5:21 AM, Alvaro Herrera alvhe...@2ndquadrant.com wrote: Fujii Masao wrote: Hi, When the archiver exits, currently reaper() restarts it only while the postmaster state is PM_RUN. This is OK in 9.4 or before because the archiver could be running on that state. But in

Re: [HACKERS] Typo fix loged vs logged.

2015-06-10 Thread Fujii Masao
On Wed, Jun 10, 2015 at 1:10 PM, David Rowley david.row...@2ndquadrant.com wrote: The attached fixes a small typo in a comment. Pushed. Thanks! -- Fujii Masao -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] Re: [COMMITTERS] pgsql: Map basebackup tablespaces using a tablespace_map file

2015-06-10 Thread Fujii Masao
On Tue, Jun 9, 2015 at 3:29 PM, Amit Kapila amit.kapil...@gmail.com wrote: On Tue, Jun 9, 2015 at 10:56 AM, Fujii Masao masao.fu...@gmail.com wrote: On Tue, Jun 9, 2015 at 1:04 PM, Amit Kapila amit.kapil...@gmail.com wrote: On Tue, Jun 9, 2015 at 9:09 AM, Fujii Masao masao.fu...@gmail.com

Re: [HACKERS] Fix logical decoding sendtime update

2015-06-10 Thread Andres Freund
On 2015-06-10 17:57:42 +0200, Shulgin, Oleksandr wrote: it turns out, that the code in WalSndWriteData is setting the timestamp of the replication message just *after* it has been sent out to the client, thus the sendtime field always reads as zero. Ugh, what a stupid bug. Thanks! Andres --

Re: [HACKERS] replication slot restart_lsn initialization

2015-06-10 Thread Gurjeet Singh
On Wed, Jun 10, 2015 at 8:36 AM, Andres Freund and...@anarazel.de wrote: On 2015-06-10 08:24:23 -0700, Gurjeet Singh wrote: On Wed, Jun 10, 2015 at 8:07 AM, Andres Freund and...@anarazel.de wrote: That doesn't look right to me. Why is this code logging a standby snapshot for physical

Re: [HACKERS] [idea] table partition + hash join

2015-06-10 Thread RosiƄski Krzysztof 2 - Detal
How to use this optimization ? select * from table join partitioned_table on ( table.part_id = partitioned_table.id and hash_func_mod(table.part_id) = hash_func_mod(partitioned_table.id) )

[HACKERS] pg_rewind failure by file deletion in source server

2015-06-10 Thread Fujii Masao
Hi, While testing pg_rewind, I got the following error and pg_rewind failed. $ pg_rewind -D ... --source-server=... -P ERROR: could not open file base/13243/16384 for reading: No such file or directory STATEMENT: SELECT path, begin, pg_read_binary_file(path, begin, len)

Re: [HACKERS] s_lock() seems too aggressive for machines with many sockets

2015-06-10 Thread Nils Goroll
As in 200%+ slower. Have you tried PTHREAD_MUTEX_ADAPTIVE_NP ? Yes. Ok, if this can be validated, we might have a new case now for which my suggestion would not be helpful. Reviewed, optimized code with short critical sections and no hotspots by design could indeed be an exception where to

Re: [HACKERS] s_lock() seems too aggressive for machines with many sockets

2015-06-10 Thread Andres Freund
On 2015-06-10 11:51:06 -0400, Jan Wieck wrote: ret = pg_atomic_fetch_sub_u32(buf-state, 1); if (ret BM_PIN_COUNT_WAITER) { pg_atomic_fetch_sub_u32(buf-state, BM_PIN_COUNT_WAITER); /* XXX: deal with race that another backend has set BM_PIN_COUNT_WAITER */ } There are atomic

[HACKERS] Fix logical decoding sendtime update

2015-06-10 Thread Shulgin, Oleksandr
Hi Hackers, it turns out, that the code in WalSndWriteData is setting the timestamp of the replication message just *after* it has been sent out to the client, thus the sendtime field always reads as zero. Attached is a trivial patch to fix this. The physical replication path already does the

Re: [HACKERS] reaper should restart archiver even on standby

2015-06-10 Thread Alvaro Herrera
Fujii Masao wrote: Agreed. The attached patch defines the macro to check whether archiver is allowed to start up or not, and uses it everywhere except sigusr1_handler. I made sigusr1_handler use a different condition because only it tries to start archiver in PM_STARTUP postmaster state and

Re: [HACKERS] jsonb - path

2015-06-10 Thread Petr Jelinek
On Wed, Jun 10, 2015 at 9:00 , Andrew Dunstan and...@dunslane.net wrote: This is an attempt to summarize What I think is now the lone outstanding jsonb issue. We need to remove the ambiguity with jsonb_delete() by renaming the variant that takes a text[] (meaning a path) as the second

Re: [HACKERS] skipping pg_log in basebackup (was Re: pg_basebackup and pg_stat_tmp directory)

2015-06-10 Thread Joshua D. Drake
On 06/10/2015 10:01 AM, Andres Freund wrote: On 2015-06-10 09:57:17 -0700, Jeff Janes wrote: Mine goal isn't that. My goal is to have a consistent backup without having to shut down the server to take a cold one, or having to manually juggle the pg_start_backup, etc. commands. A basebackup

Re: [HACKERS] s_lock() seems too aggressive for machines with many sockets

2015-06-10 Thread Robert Haas
On Wed, Jun 10, 2015 at 11:58 AM, Andres Freund and...@anarazel.de wrote: I think we should just gank spinlocks asap. The hard part is removing them from lwlock.c's slow path and the buffer headers imo. After that we should imo be fine replacing them with lwlocks. Mmmph. I'm not convinced

Re: [HACKERS] skipping pg_log in basebackup (was Re: pg_basebackup and pg_stat_tmp directory)

2015-06-10 Thread Robert Haas
On Wed, Jun 10, 2015 at 1:12 PM, Joshua D. Drake j...@commandprompt.com wrote: On 06/10/2015 10:01 AM, Andres Freund wrote: On 2015-06-10 09:57:17 -0700, Jeff Janes wrote: Mine goal isn't that. My goal is to have a consistent backup without having to shut down the server to take a cold one,

Re: [HACKERS] s_lock() seems too aggressive for machines with many sockets

2015-06-10 Thread Andres Freund
On 2015-06-10 13:52:14 -0400, Robert Haas wrote: On Wed, Jun 10, 2015 at 1:39 PM, Andres Freund and...@anarazel.de wrote: Well, not necessarily. If you can write your algorithm in a way that xadd etc are used, instead of a lock cmpxchg, you're actually never spinning on x86 as it's

Re: [HACKERS] Further issues with jsonb semantics, documentation

2015-06-10 Thread Andrew Dunstan
On 06/05/2015 01:51 PM, Andrew Dunstan wrote: On 06/05/2015 01:39 PM, Peter Geoghegan wrote: On Thu, Jun 4, 2015 at 12:10 PM, Peter Geoghegan p...@heroku.com wrote: But I agree that it's not a great contribution to science, especially since the index will be applied to the list of elements

[HACKERS] jsonb - path

2015-06-10 Thread Andrew Dunstan
This is an attempt to summarize What I think is now the lone outstanding jsonb issue. We need to remove the ambiguity with jsonb_delete() by renaming the variant that takes a text[] (meaning a path) as the second argument to jsonb_delete_path. That seems uncontroversial. We need to rename

Re: [HACKERS] Postgres GSSAPI Encryption

2015-06-10 Thread Robbie Harwood
Robbie Harwood rharw...@redhat.com writes: Stephen Frost sfr...@snowman.net writes: Robbie, * Robbie Harwood (rharw...@redhat.com) wrote: We'd I think also want a new kind of HBA entry (probably something along the lines of `hostgss` to contrast with `hostssl`), but I'm not sure what

Re: [HACKERS] skipping pg_log in basebackup (was Re: pg_basebackup and pg_stat_tmp directory)

2015-06-10 Thread Joshua D. Drake
On 06/10/2015 10:22 AM, Robert Haas wrote: On Wed, Jun 10, 2015 at 1:12 PM, Joshua D. Drake j...@commandprompt.com wrote: On 06/10/2015 10:01 AM, Andres Freund wrote: On 2015-06-10 09:57:17 -0700, Jeff Janes wrote: Mine goal isn't that. My goal is to have a consistent backup without having

Re: [HACKERS] s_lock() seems too aggressive for machines with many sockets

2015-06-10 Thread Robert Haas
On Wed, Jun 10, 2015 at 1:39 PM, Andres Freund and...@anarazel.de wrote: In the uncontended case lwlocks are just as fast as spinlocks now, with the exception of the local tracking array. They're faster if there's differences with read/write lockers. If nothing else, the spinlock calls are

Re: [HACKERS] skipping pg_log in basebackup (was Re: pg_basebackup and pg_stat_tmp directory)

2015-06-10 Thread Jeff Janes
On Wed, Jun 10, 2015 at 8:29 AM, Robert Haas robertmh...@gmail.com wrote: On Mon, Jun 8, 2015 at 12:09 AM, Michael Paquier michael.paqu...@gmail.com wrote: Recently, one of our customers has had a basebackup fail because pg_log contained files that were 8GB: FATAL: archive member

Re: [HACKERS] skipping pg_log in basebackup (was Re: pg_basebackup and pg_stat_tmp directory)

2015-06-10 Thread Andres Freund
On 2015-06-10 09:57:17 -0700, Jeff Janes wrote: Mine goal isn't that. My goal is to have a consistent backup without having to shut down the server to take a cold one, or having to manually juggle the pg_start_backup, etc. commands. A basebackup won't necessarily give you a consistent log

Re: [HACKERS] s_lock() seems too aggressive for machines with many sockets

2015-06-10 Thread Andres Freund
On 2015-06-10 13:19:14 -0400, Robert Haas wrote: On Wed, Jun 10, 2015 at 11:58 AM, Andres Freund and...@anarazel.de wrote: I think we should just gank spinlocks asap. The hard part is removing them from lwlock.c's slow path and the buffer headers imo. After that we should imo be fine

[HACKERS] minor issues in pg_rewind

2015-06-10 Thread Fujii Masao
Hi, Attached patch fixes the minor issues in pg_rewind. The fixes are * Remove invalid option character N from the third argument (valid option string) of getopt_long(). * Use pg_free() or pfree() to free the memory allocated by pg_malloc() or palloc() instead of always using free(). * Assume

Re: [HACKERS] jsonb - path

2015-06-10 Thread Andrew Dunstan
On 06/10/2015 06:08 PM, Josh Berkus wrote: WFM. So the idea is that if json_pointer is implemented as a type, then we'll have an operator for jsonb - json_pointer? Right. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] minor issues in pg_rewind

2015-06-10 Thread Michael Paquier
On Thu, Jun 11, 2015 at 2:38 AM, Fujii Masao masao.fu...@gmail.com wrote: * Remove invalid option character N from the third argument (valid option string) of getopt_long(). * Use pg_free() or pfree() to free the memory allocated by pg_malloc() or palloc() instead of always using free(). *

Re: [HACKERS] 9.5 release notes

2015-06-10 Thread Amit Langote
On 2015-06-11 PM 01:15, Bruce Momjian wrote: I have committed the first draft of the 9.5 release notes. You can view the output here: http://momjian.us/pgsql_docs/release-9-5.html and it will eventually appear here:

[HACKERS] Typo in comment in setrefs.c

2015-06-10 Thread Etsuro Fujita
I ran into a typo in a comment in setrefs.c. Patch attached. Best regards, Etsuro Fujita diff --git a/src/backend/optimizer/plan/setrefs.c b/src/backend/optimizer/plan/setrefs.c index a7f65dd..162a52e 100644 --- a/src/backend/optimizer/plan/setrefs.c +++ b/src/backend/optimizer/plan/setrefs.c @@

Re: [HACKERS] 9.5 release notes

2015-06-10 Thread David Rowley
On 11 June 2015 at 16:15, Bruce Momjian br...@momjian.us wrote: I have committed the first draft of the 9.5 release notes. You can view the output here: http://momjian.us/pgsql_docs/release-9-5.html Thanks Bruce. Would you also be able to mention something about f15821e and

Re: [HACKERS] skipping pg_log in basebackup (was Re: pg_basebackup and pg_stat_tmp directory)

2015-06-10 Thread Abhijit Menon-Sen
At 2015-06-10 13:22:27 -0400, robertmh...@gmail.com wrote: I'm not clear on which of these options you are voting for: (1) include pg_log in pg_basebackup as we do currently (2) exclude it (3) add a switch controlling whether or not it gets excluded I can live with (3), but I bet most

Re: [HACKERS] 9.5 release notes

2015-06-10 Thread Amit Kapila
On Thu, Jun 11, 2015 at 9:45 AM, Bruce Momjian br...@momjian.us wrote: I have committed the first draft of the 9.5 release notes. You can view the output here: http://momjian.us/pgsql_docs/release-9-5.html Thanks for writing the Release notes. Some comments: Have pg_basebackup

Re: [HACKERS] comment doesn't match code

2015-06-10 Thread Etsuro Fujita
On 2015/06/10 20:18, Robert Haas wrote: /* * ALTER TABLE INHERIT * * Add a parent to the child's parents. This verifies that all the columns and * check constraints of the parent appear in the child and that they have the * same data types and expressions. */ static void

Re: [HACKERS] 9.5 release notes

2015-06-10 Thread Michael Paquier
On Thu, Jun 11, 2015 at 1:15 PM, Bruce Momjian br...@momjian.us wrote: I have committed the first draft of the 9.5 release notes. You can view the output here: http://momjian.us/pgsql_docs/release-9-5.html and it will eventually appear here:

Re: [HACKERS] Minor improvement to func.sgml

2015-06-10 Thread Etsuro Fujita
On 2015/06/05 6:51, Robert Haas wrote: On Mon, Jun 1, 2015 at 10:44 PM, Etsuro Fujita fujita.ets...@lab.ntt.co.jp wrote: Here is a doc patch to add materialized views and foreign tables to database objects that pg_table_is_visible() can be used with. Good catch, as usual. Committed. Thanks

Re: [HACKERS] pg_rewind failure by file deletion in source server

2015-06-10 Thread Michael Paquier
On Thu, Jun 11, 2015 at 1:51 AM, Fujii Masao masao.fu...@gmail.com wrote: Shouldn't pg_rewind ignore that failure of operation? If the file is not found in source server, the file doesn't need to be copied to destination server obviously. So ISTM that pg_rewind safely can skip copying that

[HACKERS] DBT-3 with SF=20 got failed

2015-06-10 Thread Kouhei Kaigai
Hello, I got the following error during DBT-3 benchmark with SF=20. psql:query21.sql:50: ERROR: invalid memory alloc request size 1073741824 psql:query21.sql:50: ERROR: invalid memory alloc request size 1073741824 It looks to me Hash node tries to 1GB area using palloc0(), but it exceeds

Re: [HACKERS] Re: [COMMITTERS] pgsql: Map basebackup tablespaces using a tablespace_map file

2015-06-10 Thread Amit Kapila
On Wed, Jun 10, 2015 at 12:09 PM, Fujii Masao masao.fu...@gmail.com wrote: On Tue, Jun 9, 2015 at 3:29 PM, Amit Kapila amit.kapil...@gmail.com wrote: On Tue, Jun 9, 2015 at 10:56 AM, Fujii Masao masao.fu...@gmail.com wrote: Or what about removing tablespace_map file at the beginning of

[HACKERS] 9.5 release notes

2015-06-10 Thread Bruce Momjian
I have committed the first draft of the 9.5 release notes. You can view the output here: http://momjian.us/pgsql_docs/release-9-5.html and it will eventually appear here: http://www.postgresql.org/docs/devel/static/release.html I am ready to make suggested adjustments,