[HACKERS] 10.0

Hi, There is a long-running thread on pgsql-hackers on whether 9.6 should instead be called 10.0. Initially, opinions were mixed, but consensus seems now to have emerged that 10.0 is a good choice, with the major hesitation being that we've already released 9.6beta1, and therefore we might not

Re: [HACKERS] pg_basebackup, pg_receivexlog and data durability (was: silent data loss with ext4 / all current versions)

On 13.05.2016 9:39, Michael Paquier wrote: Hi all, Beginning a new thread because the ext4 issues are closed, and because pg_basebackup data durability meritates a new thread. And in short about the problem: pg_basebackup makes no effort in being sure that the data it backs up is on disk,

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On Sat, Apr 30, 2016 at 8:46 PM, Joshua Drake wrote: > Oh, absolutely. I was just pointing out how a lot of companies are hoarding > talent internally for no productive purpose. Wow, really? I disagree both with the idea that this is happening and with your

Re: [HACKERS] Perf Benchmarking and regression.

On Fri, May 13, 2016 at 7:08 AM, Ashutosh Sharma wrote: > Following are the performance results for read write test observed with > different numbers of "backend_flush_after". > > 1) backend_flush_after = 256kb (32*8kb), tps = 10841.178815 > 2) backend_flush_after = 512kb

Re: [HACKERS] Postgres_fdw join pushdown - getting server crash in left outer join of three table

On Wed, Mar 23, 2016 at 12:53 PM, Robert Haas wrote: > On Wed, Mar 23, 2016 at 5:24 AM, Rajkumar Raghuwanshi > wrote: >> Thanks Ashutosh for the patch. I have apply and retested it, now not getting >> server crash. > > Thanks for the

Re: [HACKERS] Error during restore - dump taken with pg_dumpall -c option

* Rushabh Lathia (rushabh.lat...@gmail.com) wrote: > On master branch when we do pg_dumpall with -c option, I can see that > it also dumping the "DROP ROLE pg_signal_backend", which seems wrong. > Because when you restore the dump, its throwing an error > "ERROR: cannot drop role

Re: [HACKERS] Perf Benchmarking and regression.

Hi, Following are the performance results for read write test observed with different numbers of "*backend_flush_after*". 1) backend_flush_after = *256kb* (32*8kb), tps = *10841.178815* 2) backend_flush_after = *512kb* (64*8kb), tps = *11098.702707* 3) backend_flush_after = *1MB* (128*8kb), tps

Re: [HACKERS] Error during restore - dump taken with pg_dumpall -c option

On Thu, May 12, 2016 at 9:48 PM, Fabrízio de Royes Mello wrote: > > > Em quinta-feira, 12 de maio de 2016, Rushabh Lathia > escreveu: >> >> >> On master branch when we do pg_dumpall with -c option, I can see that >> it also dumping the "DROP

Re: [HACKERS] Use %u to print user mapping's umid and userid

On 2016/05/13 3:53, Tom Lane wrote: Robert Haas writes: Regardless of what approach we take, I disagree that this needs to be fixed in 9.6. Agreed. This is only a cosmetic issue, and it's only going to be visible to a very small group of people, so we can leave it

[HACKERS] pg_basebackup, pg_receivexlog and data durability (was: silent data loss with ext4 / all current versions)

Hi all, Beginning a new thread because the ext4 issues are closed, and because pg_basebackup data durability meritates a new thread. And in short about the problem: pg_basebackup makes no effort in being sure that the data it backs up is on disk, which is bad... One possible recommendation is to

<    1   2