Re: [HACKERS] [sqlsmith] Failed assertion in parallel worker (ExecInitSubPlan)

On Fri, May 13, 2016 at 10:31 AM, Amit Kapila wrote: > Here I want to ask base rels which are plain rels? > > It might be that I am missing something, but if we debug the serial plan > for original query [1] for which this issue is reported, we have noticed > that PlaceHolderVars that contain sub

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 > > > different numbers of "backend_flush_after". >

[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 pro

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. > > ​​You started this sub-thread with: > > "If I unde

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 do...​ Our scheme is, in you

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 >>> hoarding >>> talent internally for no productive purpos

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 Fri, May 13, 2016 at 12:12 P

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 taken over by marketing people, and > software quality wil

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 brought up my own thoughts on th

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 >> software quality wi

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 just > > as we disc

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 is

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 working, or that breaks network communication pro

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 standard, we'd never have

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 > in. -1 If I understand

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 committed to be honest. And

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 numbers. And for what it's

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: > If we don't want to stick with the current practice of debating when > to bump the same

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 me > know if it nee

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) while backing up files? That

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

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 point, because nobody has t

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: REL_10_0_STABLE. That wo

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 have this type of >> discussion again in f

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 do

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 future years ... If pg_log

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 via pgsql-hackers mailing

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 cycles, electricity, tax

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 bump the same digit, then let's agree that 10.0 will follow 9.6 and > > after that we'll bump

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 t

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 releases per year.

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 I

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

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 to >> think we'd try

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: >> >>> Anyway, all of this is a moot point

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 future

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 version on the > year,

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] 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 two-part version numbering scheme. > Man, I h

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 be 10.0 no matter what changes we put >> in. > >

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 over to a two-part version numbering scheme.

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 power to >> tell the various

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 two-part version numberi

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 > priorities. Features shouldn't g

Re: [HACKERS] 10.0

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 two-part version numbering scheme. To be > specific: > > * This year's

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

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 power to tell the various companies what to do. We're just lucky that everyone is still

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

On 05/13/2016 12:05 PM, Robert Haas wrote: 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: The difference being one of coopetition versions competition for the betterment of the community. If

Re: [HACKERS] 10.0

Andres Freund writes: > I'm in favor of doing something more radical than just stripping one > digit off. We've tried (and only partially failed) to educate users that > $major.$minor updates are the big ones; if we change that to essentially > be $major.$micro, we'll have people not updating and

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 size; with a noticeab

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. > I'm for it. > Not

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 a new idea, but I think it

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 we put >> in. > > Here's

Re: [HACKERS] Academic help for Postgres

On Thu, May 12, 2016 at 09:47:02AM +0200, Michael Banck wrote: > On Thu, May 12, 2016 at 08:57:34AM +0800, Craig Ringer wrote: > > On 11 May 2016 at 22:20, Bruce Momjian wrote: > > > I am giving a keynote at an IEEE database conference in Helsinki next > > > week (http://icde2016.fi/). (Yes, I am

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 time > * Company(1

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

On 05/13/2016 11:48 AM, Robert Haas wrote: > 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 collabor

Re: [HACKERS] 10.0

Josh berkus writes: > On 05/13/2016 08:19 AM, Bruce Momjian wrote: >> Someone mentioned how Postgres 8.5 became 9.0, but then someone else >> said the change was made during alpha releases, not beta. Can someone >> dig up the details? > /me digs through the announcement archives ... > We changed

Re: [HACKERS] 10.0

On 05/13/2016 08:19 AM, Bruce Momjian wrote: >> > Thoughts? Is it crazy to go from 9.6beta1 to 10.0beta2? What would >> > actually be involved in making the change? > Someone mentioned how Postgres 8.5 became 9.0, but then someone else > said the change was made during alpha releases, not beta.

Re: [HACKERS] 10.0

On Fri, May 13, 2016 at 1:46 PM, Robert Haas wrote: > On Fri, May 13, 2016 at 2:45 PM, Vik Fearing wrote: >> On 05/13/2016 08:31 PM, Alvaro Herrera wrote: >>> I think the next version should be 10.0 no matter what changes we put >>> in. >> >> +1 >> >> Let's even stamp it 10.0devel from the get-g

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 8.0 that on the basis of the

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 beneficial to the > project

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 should be 10.0 no matter w

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

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 Suppo

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 >> > different numbers of "backend_flush_after". >>

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 into > master. The

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: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 vers

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 http://ww

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, 24x7

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. Althoug

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 the PLpgSQL_execstate, w

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 my opinion: 9.5 - k

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 (32*8kb), tps = 10841.178

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 mailto:robertmh...@gmail.com>>: From a non-hacker... From a DBA/application-developer perspective while there are many exiting features in 9.6 I'd expect more from 10.0, like some of these fe

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

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

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 have >> > already coded in 9.6 checks for feature support. >

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 single >>> digit. >> Is that likely? Tha

Re: [HACKERS] 10.0

På fredag 13. mai 2016 kl. 18:22:00, skrev Magnus Hagander mailto:mag...@hagander.net>>: On Fri, May 13, 2016 at 5:42 PM, Andreas Joseph Krogh mailto:andr...@visena.com>> wrote: På fredag 13. mai 2016 kl. 17:05:23, skrev Robert Haas mailto:robertmh...@gmail.com>>: Hi, There is a long-running thr

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 doin

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 an issue (I never heard of it being

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 were mixed, but consen

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 version number is only a single digi

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 in style! ;) It would sure put a premi

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 9.6 checks for feature support. > > >

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 this is happening and with

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 the bigger issue will be apps that have been written > >> > assumin

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 is only a single d

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 lea

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

Re: [HACKERS] 10.0

På fredag 13. mai 2016 kl. 17:05:23, skrev Robert Haas mailto: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 were mixed, but consensus seems now to have emerged that 10.0 is a good choice, with the

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 suspect that won't be an issue (I never

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 confusing.

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 never heard of it being for 7.5, > w

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 smattered all over

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 to have emerged tha

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 > hesitation being that we'v

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

  1   2   >