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

[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

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

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] 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] 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] 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] 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] 10.0

On 13 May 2016 at 16:05, Robert Haas wrote: > > 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 >

Re: [HACKERS] 10.0

On 13 May 2016 at 16:29, Dave Page wrote: > On Fri, May 13, 2016 at 4:23 PM, Thom Brown wrote: >> >> Well, one potential issues is that there may be projects which have >> already coded in 9.6 checks for feature support. > > I suspect that won't be an issue (I

Re: [HACKERS] 10.0

Stephen Frost writes: > On Friday, May 13, 2016, Bruce Momjian wrote: >> On Fri, May 13, 2016 at 12:05:34PM -0400, Stephen Frost wrote: >>> Let's just go with 2016 instead then. >> We tried, that, "Postgres95". ;-) > Even better, we're being retro! It's

Re: [HACKERS] 10.0

> On 13 May 2016, at 17:24, Magnus Hagander wrote: > >> On Fri, May 13, 2016 at 5:29 PM, Dave Page wrote: >> On Fri, May 13, 2016 at 4:23 PM, Thom Brown wrote: >> > >> > Well, one potential issues is that there may be projects which

Re: [HACKERS] 10.0

On Fri, May 13, 2016 at 4:23 PM, Thom Brown wrote: > > Well, one potential issues is that there may be projects which have > already coded in 9.6 checks for feature support. I suspect that won't be an issue (I never heard of it being for 7.5, which was released as 8.0 - but is

Re: [HACKERS] 10.0

Robert Haas writes: > There is a long-running thread on pgsql-hackers on whether 9.6 should > instead be called 10.0. First I've seen it mentioned here. I think you are just about exactly one week too late to bring this up. Once we've shipped a beta, rebranding is way too

Re: [HACKERS] 10.0

On 2016-05-13 10:34, Thom Brown wrote: On 13 May 2016 at 16:29, Dave Page wrote: On Fri, May 13, 2016 at 4:23 PM, Thom Brown wrote: Well, one potential issues is that there may be projects which have already coded in 9.6 checks for feature support. I

Re: [HACKERS] 10.0

On Fri, May 13, 2016 at 5:29 PM, Dave Page wrote: > On Fri, May 13, 2016 at 4:23 PM, Thom Brown wrote: > > > > Well, one potential issues is that there may be projects which have > > already coded in 9.6 checks for feature support. > > I suspect that won't be

Re: [HACKERS] 10.0

På fredag 13. mai 2016 kl. 18:22:00, skrev Magnus Hagander >: On Fri, May 13, 2016 at 5:42 PM, Andreas Joseph Krogh > wrote: På fredag 13. mai 2016 kl. 17:05:23, skrev Robert Haas

Re: [HACKERS] 10.0

David Fetter writes: > On Fri, May 13, 2016 at 04:34:34PM +0100, Thom Brown wrote: >> On 13 May 2016 at 16:29, Dave Page wrote: >>> I imagine the bigger issue will be apps that have been written >>> assuming the first part of the version number is only a

Re: [HACKERS] 10.0

On 13 May 2016 at 16:19, Bruce Momjian wrote: > On Fri, May 13, 2016 at 11:05:23AM -0400, Robert Haas wrote: >> 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

Re: [HACKERS] 10.0

* Dave Page (dp...@pgadmin.org) wrote: > I imagine the bigger issue will be apps that have been written > assuming the first part of the version number is only a single digit. Let's just go with 2016 instead then. At least then users would see how old the version they're running is (I was just

Re: [HACKERS] 10.0

On Fri, May 13, 2016 at 5:08 PM, Bruce Momjian wrote: > On Fri, May 13, 2016 at 12:05:34PM -0400, Stephen Frost wrote: >> * Dave Page (dp...@pgadmin.org) wrote: >> > I imagine the bigger issue will be apps that have been written >> > assuming the first part of the version number

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

On 05/13/2016 07:42 AM, Robert Haas wrote: 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

Re: [HACKERS] 10.0

On Fri, May 13, 2016 at 04:34:34PM +0100, Thom Brown wrote: > On 13 May 2016 at 16:29, Dave Page wrote: > > On Fri, May 13, 2016 at 4:23 PM, Thom Brown wrote: > >> > >> Well, one potential issues is that there may be projects which > >> have already coded in

Re: [HACKERS] 10.0

On Friday, May 13, 2016, Dave Page wrote: > On Fri, May 13, 2016 at 5:08 PM, Bruce Momjian > wrote: > > On Fri, May 13, 2016 at 12:05:34PM -0400, Stephen Frost wrote: > >> * Dave Page (dp...@pgadmin.org ) wrote: > >> > I imagine

[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] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On Fri, May 13, 2016 at 09:12:23AM -0700, Joshua Drake wrote: > There was no disrespect intended. I was trying to push forth an idea that > multi-company team collaboration is better for the community than single > company team collaboration. I will stand by that assertion. Uh, we are already

Re: [HACKERS] 10.0

On Fri, May 13, 2016 at 11:05:23AM -0400, Robert Haas wrote: > 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

Re: [HACKERS] 10.0

På fredag 13. mai 2016 kl. 17:05:23, skrev Robert Haas >: 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

Re: [HACKERS] 10.0

On Fri, May 13, 2016 at 12:05:34PM -0400, Stephen Frost wrote: > * Dave Page (dp...@pgadmin.org) wrote: > > I imagine the bigger issue will be apps that have been written > > assuming the first part of the version number is only a single digit. > > Let's just go with 2016 instead then. > > At

Re: [HACKERS] 10.0

On Friday, May 13, 2016, Bruce Momjian wrote: > On Fri, May 13, 2016 at 12:05:34PM -0400, Stephen Frost wrote: > > * Dave Page (dp...@pgadmin.org ) wrote: > > > I imagine the bigger issue will be apps that have been written > > > assuming the first part of the

Re: [HACKERS] 10.0

On Fri, May 13, 2016 at 5:42 PM, Andreas Joseph Krogh wrote: > På fredag 13. mai 2016 kl. 17:05:23, skrev Robert Haas < > robertmh...@gmail.com>: > > Hi, > > There is a long-running thread on pgsql-hackers on whether 9.6 should > instead be called 10.0. Initially, opinions

Re: [HACKERS] 10.0

On Fri, May 13, 2016 at 12:30:47PM -0400, Tom Lane wrote: > > I think you could, though, make an argument that breaking such code > after beta1 is a bit unfair. People expect to be able to do > compatibility testing with a new major version starting with beta1. One could, but I wouldn't find it

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

On 05/13/2016 09:28 AM, Bruce Momjian wrote: On Fri, May 13, 2016 at 09:12:23AM -0700, Joshua Drake wrote: There was no disrespect intended. I was trying to push forth an idea that multi-company team collaboration is better for the community than single company team collaboration. I will stand

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

On Fri, May 13, 2016 at 09:35:40AM -0700, Joshua Drake wrote: > On 05/13/2016 09:28 AM, Bruce Momjian wrote: > >On Fri, May 13, 2016 at 09:12:23AM -0700, Joshua Drake wrote: > >>There was no disrespect intended. I was trying to push forth an idea that > >>multi-company team collaboration is better

Re: [HACKERS] 10.0

On 13/05/16 17:42, Andreas Joseph Krogh wrote: På fredag 13. mai 2016 kl. 17:05:23, skrev Robert Haas >: From a non-hacker... From a DBA/application-developer perspective while there are many exiting features in 9.6 I'd expect more from

Re: [HACKERS] Perf Benchmarking and regression.

On 2016-05-13 10:20:04 -0400, Robert Haas wrote: > 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

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

On 05/13/2016 09:40 AM, Bruce Momjian wrote: On Fri, May 13, 2016 at 09:35:40AM -0700, Joshua Drake wrote: On 05/13/2016 09:28 AM, Bruce Momjian wrote: On Fri, May 13, 2016 at 09:12:23AM -0700, Joshua Drake wrote: There was no disrespect intended. I was trying to push forth an idea that

Re: [HACKERS] 10.0

On 5/13/16, Bruce Momjian wrote: > On Fri, May 13, 2016 at 11:05:23AM -0400, Robert Haas wrote: >> The major arguments advanced in favor of 10.0 are: >> >> - There are a lot of exciting features in this release. If I'm mot mistaken each release introduced exciting features. In

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

On Fri, May 13, 2016 at 2:05 PM, Robert Haas wrote: > Now, where this gets tricky is when it comes down to whether the > end-product of that effort is something the community wants. We all > need to be careful not to make our corporate priorities into community >

Re: [HACKERS] 10.0

On Fri, May 13, 2016 at 03:48:39PM -0500, Merlin Moncure wrote: > Any versioning system that removes subjective criteria is good. These > debates in interminable and always have been. Personally I would go > with something even more antiseptic like basing the version on the > year, where year is

Re: [HACKERS] 10.0

On Fri, May 13, 2016 at 02:06:26PM -0700, Josh Berkus wrote: > On 05/13/2016 02:00 PM, Tom Lane wrote: > > I still don't like that much, and just thought of another reason why: > > it would foreclose doing two major releases per year. We have debated > > that sort of schedule in the past. While

Re: [HACKERS] 10.0

"Joshua D. Drake" writes: > I mean we haven't yet actually identified a problem we are trying to > solve have we? The problem I'd like to solve is not having to have this type of discussion again in future years ... regards, tom lane -- Sent

Re: [HACKERS] 10.0

* Tom Lane wrote: So I think we should solve these problems at a stroke, and save ourselves lots of breath in the future, by getting rid of the whole "major major" idea and going over to a two-part version numbering scheme. To be specific: * This year's major release will be 9.6.0, with minor

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

On 13 May 2016, at 21:42, Josh berkus wrote: > On 05/13/2016 01:04 PM, Joshua D. Drake wrote: >> On 05/13/2016 12:03 PM, Josh berkus wrote: >>> On 05/13/2016 11:48 AM, Robert Haas wrote: On Fri, May 13, 2016 at 12:12 PM, Joshua D. Drake wrote:

Re: [HACKERS] 10.0

On Friday, May 13, 2016, Tom Lane wrote: > Robert Haas > writes: > > On Fri, May 13, 2016 at 2:49 PM, Tom Lane > wrote: > > > If we don't want to stick with the current practice of debating when > > to

Re: [HACKERS] 10.0

On 05/13/2016 05:12 PM, Tom Lane wrote: An analogy that might get some traction among database geeks is that version numbers are a sort of surrogate key, and assigning meaning to surrogate keys is a bad idea. :-) I agree year-based numbers will cause us grief. I

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

On 05/13/2016 01:42 PM, Josh berkus wrote: On 05/13/2016 01:04 PM, Joshua D. Drake wrote: On 05/13/2016 12:03 PM, Josh berkus wrote: On 05/13/2016 11:48 AM, Robert Haas wrote: On Fri, May 13, 2016 at 12:12 PM, Joshua D. Drake wrote: Anyway, all of this is a moot

Re: [HACKERS] Academic help for Postgres

On Sat, May 14, 2016 at 7:13 AM, Bruce Momjian wrote: > I have incorporated suggestions from this email thread into my IEEE talk > for next week: > > http://momjian.us/main/writings/pgsql/ieee.pdf > > You will see most of it in the new slides toward the end. Please let

Re: [HACKERS] 10.0

On 05/13/2016 01:15 PM, Robert Haas wrote: > On Fri, May 13, 2016 at 2:49 PM, Tom Lane wrote: >> So I think we should solve these problems at a stroke, and save ourselves >> lots of breath in the future, by getting rid of the whole "major major" >> idea and going over to a

Re: [HACKERS] 10.0

On 14/05/16 09:31, David G. Johnston wrote: On Friday, May 13, 2016, Tom Lane > wrote: Robert Haas > writes: > On Fri, May 13, 2016 at 2:49 PM, Tom Lane > wrote:

Re: [HACKERS] 10.0

Robert Haas writes: > On Fri, May 13, 2016 at 2:49 PM, Tom Lane wrote: >> So I think we should solve these problems at a stroke, and save ourselves >> lots of breath in the future, by getting rid of the whole "major major" >> idea and going over to a

Re: [HACKERS] 10.0

On Fri, May 13, 2016 at 1:49 PM, Tom Lane wrote: > Alvaro Herrera writes: >> Josh berkus wrote: >>> Anyway, can we come up with a consensus of some minimum changes it will >>> take to make the next version 10.0? > >> I think the next version should

Re: [HACKERS] 10.0

On 05/13/2016 02:36 PM, Tom Lane wrote: "Joshua D. Drake" writes: I mean we haven't yet actually identified a problem we are trying to solve have we? The problem I'd like to solve is not having to have this type of discussion again in future years ... Amen. JD

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

On 05/13/2016 01:04 PM, Joshua D. Drake wrote: > On 05/13/2016 12:03 PM, Josh berkus wrote: >> On 05/13/2016 11:48 AM, Robert Haas wrote: >>> On Fri, May 13, 2016 at 12:12 PM, Joshua D. Drake >>> wrote: > >> Anyway, all of this is a moot point, because nobody has the

Re: [HACKERS] 10.0

On 05/13/2016 02:00 PM, Tom Lane wrote: > I still don't like that much, and just thought of another reason why: > it would foreclose doing two major releases per year. We have debated > that sort of schedule in the past. While I don't see any reason to > think we'd try to do it in the near

Re: [HACKERS] 10.0

On Fri, May 13, 2016 at 05:36:50PM -0400, Tom Lane wrote: > "Joshua D. Drake" writes: > > I mean we haven't yet actually identified a problem we are trying to > > solve have we? > > The problem I'd like to solve is not having to have this type of > discussion again in

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

On Fri, May 13, 2016 at 6:05 PM, Joshua D. Drake wrote: > On 05/13/2016 01:42 PM, Josh berkus wrote: > >> On 05/13/2016 01:04 PM, Joshua D. Drake wrote: >> >>> On 05/13/2016 12:03 PM, Josh berkus wrote: >>> On 05/13/2016 11:48 AM, Robert Haas wrote: > On

Re: [HACKERS] 10.0

On Fri, May 13, 2016 at 10:18 PM, Mark Dilger wrote: > > My main concern is that a commitment to never, ever break backwards > compatibility is a commitment to obsolescence. ​​You started this sub-thread with: "If I understand correctly..." ​I'm not sure that you

[HACKERS] Losing memory references - SRF + SPI

I am writing a function that returns a set of tuples by using also the PostGIS. Thuis, I am using SRF too. It successfully returns the expected result when it has at most 4 tuples. However, this is not the case when more than 4 tuples have to be returned. When I debug the code, I found that the

Re: [HACKERS] Perf Benchmarking and regression.

On Fri, May 13, 2016 at 11:13 PM, Andres Freund wrote: > > On 2016-05-13 10:20:04 -0400, Robert Haas wrote: > > On Fri, May 13, 2016 at 7:08 AM, Ashutosh Sharma wrote: > > > Following are the performance results for read write test observed with > > >

Re: [HACKERS] 10.0

> On May 13, 2016, at 6:33 PM, David G. Johnston > wrote: > > On Fri, May 13, 2016 at 7:32 PM, Mark Dilger wrote: > > Any project that starts inflating its numbering scheme sends a message to > users of the form, "hey, we've just been

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

On Fri, May 13, 2016 at 12:12 PM, Joshua D. Drake wrote: > On 05/13/2016 07:42 AM, Robert Haas wrote: > >> 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 >>>

Re: [HACKERS] 10.0

> On May 13, 2016, at 8:26 PM, David G. Johnston > wrote: > > On Fri, May 13, 2016 at 10:18 PM, Mark Dilger wrote: > > My main concern is that a commitment to never, ever break backwards > compatibility is a commitment to obsolescence. >

Re: [HACKERS] 10.0

> On May 13, 2016, at 11:31 AM, Alvaro Herrera wrote: > > Josh berkus wrote: > >> Anyway, can we come up with a consensus of some minimum changes it will >> take to make the next version 10.0? > > I think the next version should be 10.0 no matter what changes we put

Re: [HACKERS] 10.0

Mark Dilger writes: > A major number change should indicate that something even bigger than on-disk > compatibility has changed, such as a change that precludes even a dump and > restore from working, or that breaks network communication protocols, etc. If that were the

Re: [HACKERS] 10.0

> On May 13, 2016, at 5:00 PM, Tom Lane wrote: > > Mark Dilger writes: >> A major number change should indicate that something even bigger than on-disk >> compatibility has changed, such as a change that precludes even a dump and >> restore from

Re: [HACKERS] 10.0

On Fri, May 13, 2016 at 6:44 PM, Michael Banck wrote: > On Fri, May 13, 2016 at 05:31:00PM -0400, David G. Johnston wrote: > > The underlying premise, for me, of choosing .4 or .5 was that presently > we > > discontinue support after 5 years/releases. A new .0 would come out

Re: [HACKERS] 10.0

On Fri, May 13, 2016 at 7:32 PM, Mark Dilger wrote: > > Any project that starts inflating its numbering scheme sends a message to > users of the form, "hey, we've just been taken over by marketing people, > and > software quality will go down from now on." > ​Tom

Re: [HACKERS] 10.0

On 05/13/2016 05:22 PM, Mark Dilger wrote: >>> >> Any project that starts inflating its numbering scheme sends a message to >>> >> users of the form, "hey, we've just been taken over by marketing people, >>> >> and >>> >> software quality will go down from now on." >> > >> > I don't think this

Re: [HACKERS] 10.0

> On May 13, 2016, at 5:49 PM, Josh berkus wrote: > > On 05/13/2016 05:22 PM, Mark Dilger wrote: >> Any project that starts inflating its numbering scheme sends a message to >> users of the form, "hey, we've just been taken over by marketing people, >> and >>

Re: [HACKERS] 10.0

On 5/13/16, Robert Haas wrote: > On Fri, May 13, 2016 at 2:49 PM, Tom Lane wrote: >> So I think we should solve these problems at a stroke, and save ourselves >> lots of breath in the future, by getting rid of the whole "major major" >> idea and going

Re: [HACKERS] 10.0

Merlin Moncure writes: > Any versioning system that removes subjective criteria is good. These > debates in interminable and always have been. Yeah, I got bored of the topic after about 8.0 ;-) > Personally I would go > with something even more antiseptic like basing the

Re: [HACKERS] 10.0

Josh berkus writes: > On 05/13/2016 02:00 PM, Tom Lane wrote: >> I still don't like that much, and just thought of another reason why: >> it would foreclose doing two major releases per year. We have debated >> that sort of schedule in the past. While I don't see any reason

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

On Fri, May 13, 2016 at 11:49 PM, Alex Ignatov wrote: > > On 13.05.2016 9:39, Michael Paquier wrote: > Do we have any confidence that data file is not being corrupted? I.e > contains some corrupted page? Can pg_basebackup check page checksum (db init > with initdb -k)

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

On Fri, May 13, 2016 at 11:14 PM, Robert Haas wrote: > So, barring objections, I intend to apply the attached fixup patch, > which replaces Michael's logic with Ashutosh's logic and rewrites the > comments such to be much more explicit. Re-oops. I didn't check what was

Re: [HACKERS] 10.0

On Fri, May 13, 2016 at 11:14 PM, Bruce Momjian wrote: > On Fri, May 13, 2016 at 02:06:26PM -0700, Josh Berkus wrote: > > On 05/13/2016 02:00 PM, Tom Lane wrote: > > > I still don't like that much, and just thought of another reason why: > > > it would foreclose doing two major

Re: [HACKERS] 10.0

On 05/13/2016 02:22 PM, Magnus Hagander wrote: Using something like .2.0 for the second one in the same year could be suggested, but to me that sounds like the worst of both worlds. The amount of brain cycles, electricity, taxes on internet connectivity and transcontinental data spent on

Re: [HACKERS] 10.0

On May 13, 2016 23:27, "Joshua D. Drake" wrote: > > On 05/13/2016 02:22 PM, Magnus Hagander wrote: >> >> > >> Using something like .2.0 for the second one in the same year >> could be suggested, but to me that sounds like the worst of both worlds. > > > The amount of brain

Re: [HACKERS] 10.0

Bruce Momjian writes: > On Fri, May 13, 2016 at 05:36:50PM -0400, Tom Lane wrote: >> "Joshua D. Drake" writes: >>> I mean we haven't yet actually identified a problem we are trying to >>> solve have we? >> The problem I'd like to solve is not having to

Re: [HACKERS] 10.0

Andrew Dunstan writes: > I don't have any strong opinions about this. It's essentially a > marketing decision, and I'm happy to leave that to others. If and when > we do change, I'd like to put in a modest request that we add an extra _ > to the branch names, like this:

Re: [HACKERS] 10.0

On Fri, May 13, 2016 at 9:15 PM, Robert Haas wrote: > Man, I hate version number inflation. I'm running Firefox 45.0.2, and > I think that's crazy. It hit 1.0 when were at aversion 7.4! I don't see what's wrong with large numbers, it's not like there's a shortage of

Re: [HACKERS] 10.0

Josh berkus wrote: > Anyway, can we come up with a consensus of some minimum changes it will > take to make the next version 10.0? I think the next version should be 10.0 no matter what changes we put in. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development,

Re: [HACKERS] 10.0

On 05/13/2016 11:31 AM, Alvaro Herrera wrote: > Josh berkus wrote: > >> Anyway, can we come up with a consensus of some minimum changes it will >> take to make the next version 10.0? > > I think the next version should be 10.0 no matter what changes we put > in. > Well, if we adopt 2-part

Re: [HACKERS] 10.0

On 13/05/16 20:31, Alvaro Herrera wrote: Josh berkus wrote: Anyway, can we come up with a consensus of some minimum changes it will take to make the next version 10.0? I think the next version should be 10.0 no matter what changes we put in. +1 -- Petr Jelinek

Re: [HACKERS] delta relations in AFTER triggers

On Thu, Jan 22, 2015 at 02:41:42PM +, Kevin Grittner wrote: > Robert Haas wrote: > > > Another idea is to change what actually gets passed to the parser > > callback. Right now we just pass the PLpgSQL_expr. If we created a > > new structure that contained that plus

Re: [HACKERS] 10.0

On 05/13/2016 09:30 AM, Tom Lane wrote: > More generally, rebranding after beta1 sends a very public signal that > we're a bunch of losers who couldn't make up our minds in a timely > fashion. We should have discussed this last month; now I think we're > stuck with a decision by default.

Re: [HACKERS] delta relations in AFTER triggers

On Fri, May 13, 2016 at 1:02 PM, David Fetter wrote: > On Thu, Jan 22, 2015 at 02:41:42PM +, Kevin Grittner wrote: >> [ideas on how to pass around references to ephemeral relations] > > [almost 17 months later] > > It seems like now is getting close to the time to get this

Re: [HACKERS] 10.0

On Fri, May 13, 2016 at 03:31:37PM -0300, Alvaro Herrera wrote: > Josh berkus wrote: > > > Anyway, can we come up with a consensus of some minimum changes it will > > take to make the next version 10.0? > > I think the next version should be 10.0 no matter what changes we put > in. +1 Cheers,

Re: [HACKERS] 10.0

On 05/13/2016 11:49 AM, Tom Lane wrote: > Alvaro Herrera writes: >> Josh berkus wrote: >>> Anyway, can we come up with a consensus of some minimum changes it will >>> take to make the next version 10.0? > >> I think the next version should be 10.0 no matter what changes

Re: [HACKERS] 10.0

Hi, On 2016-05-13 12:36:00 -0700, Josh berkus wrote: > On 05/13/2016 11:49 AM, Tom Lane wrote: > > Alvaro Herrera writes: > >> Josh berkus wrote: > > No confusion, no surprises, no debate ever again about what the next > > version number is. > > > > This is by no means

Re: [HACKERS] 10.0

Josh berkus writes: > On 05/13/2016 11:49 AM, Tom Lane wrote: >> So I think we should solve these problems at a stroke, and save ourselves >> lots of breath in the future, by getting rid of the whole "major major" >> idea and going over to a two-part version numbering scheme.

Re: [HACKERS] Perf Benchmarking and regression.

On 2016-05-13 14:43:15 -0400, Robert Haas wrote: > On Fri, May 13, 2016 at 1:43 PM, Andres Freund wrote: > > I just want to emphasize what we're discussing here is a bit of an > > extreme setup. A workload that's bigger than shared buffers, but smaller > > than the OS's cache

Re: [HACKERS] 10.0

Josh berkus wrote: > Well, if we adopt 2-part version numbers, it will be. Maybe that's the > easiest thing? Then we never have to have this discussion again, which > certainly appeals to me ... -1 -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7

Re: [HACKERS] 10.0

On 05/13/2016 08:31 PM, Alvaro Herrera wrote: > Josh berkus wrote: > >> Anyway, can we come up with a consensus of some minimum changes it will >> take to make the next version 10.0? > > I think the next version should be 10.0 no matter what changes we put > in. +1 Let's even stamp it

Re: [HACKERS] 10.0

Alvaro Herrera writes: > Josh berkus wrote: >> Anyway, can we come up with a consensus of some minimum changes it will >> take to make the next version 10.0? > I think the next version should be 10.0 no matter what changes we put > in. Here's my two cents: we called

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

On Fri, May 13, 2016 at 12:35 PM, Joshua D. Drake wrote: > Hey, if I am wrong that's awesome. The impression I have is the general > workflow is this: > > * Company(1) discusses feature with community > * Company(1) works on patch/feature for a period of

Re: [HACKERS] Perf Benchmarking and regression.

On Fri, May 13, 2016 at 1:43 PM, Andres Freund wrote: > On 2016-05-13 10:20:04 -0400, Robert Haas wrote: >> On Fri, May 13, 2016 at 7:08 AM, Ashutosh Sharma >> wrote: >> > Following are the performance results for read write test observed with >> >

Re: [HACKERS] 10.0

On Fri, May 13, 2016 at 2:45 PM, Vik Fearing wrote: > On 05/13/2016 08:31 PM, Alvaro Herrera wrote: >> Josh berkus wrote: >> >>> Anyway, can we come up with a consensus of some minimum changes it will >>> take to make the next version 10.0? >> >> I think the next version

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

On Fri, May 13, 2016 at 12:12 PM, Joshua D. Drake wrote: > Singular point contribution is not the point of my argument. My point is > that if three people from EDB and three people from Citus got together and > worked on a project in full collaboration it would be more

  1   2   >