Re: [HACKERS] Releasing in September

2016-01-20 Thread Peter Geoghegan
On Wed, Jan 20, 2016 at 8:32 PM, Michael Paquier wrote: > Perhaps some people are more interested in implementing new > features than working on bugs and would just continue hacking and > arguing about new features, at least a stability period may attract > more

Re: [HACKERS] Releasing in September

2016-01-20 Thread Peter Geoghegan
On Wed, Jan 20, 2016 at 9:37 PM, Michael Paquier wrote: > We have automatic buildfarm coverage on many platforms. Perhaps we > could live without that with a buildfarm module though. It's not clear that buildfarm coverage makes sense for sqlsmith. If it does make

Re: [HACKERS] postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs)

2016-01-20 Thread Ashutosh Bapat
On Thu, Jan 21, 2016 at 2:07 AM, Robert Haas wrote: > > Well, we kind of need to get it right, not just be guessing. > > It looks to me as though GetConnection() only uses the user ID as a > cache lookup key. What it's trying to do is ensure that if user A and > user B

Re: [HACKERS] Combining Aggregates

2016-01-20 Thread David Rowley
On 21 January 2016 at 08:06, Robert Haas wrote: > On Wed, Jan 20, 2016 at 7:38 AM, David Rowley > wrote: > > Agreed. So I've attached a version of the patch which does not have any > of > > the serialise/deserialise stuff in it. > > I

Re: [HACKERS] Releasing in September

2016-01-20 Thread Peter Geoghegan
On Wed, Jan 20, 2016 at 8:23 PM, Michael Paquier wrote: > Another tool that we had better IMO put some efforts in porting > into core is sqlsmith, which would actually be a complete rewrite > because the upstream code is under GPL license and depends on libpqxx. Then

Re: [HACKERS] Combining Aggregates

2016-01-20 Thread David Rowley
On 21 January 2016 at 04:59, Robert Haas wrote: > On Wed, Jan 20, 2016 at 7:53 AM, David Rowley > wrote: > > On 21 January 2016 at 01:44, Robert Haas wrote: > >> > >> On Wed, Jan 20, 2016 at 7:38 AM, David Rowley > >>

Re: [HACKERS] Combining Aggregates

2016-01-20 Thread David Rowley
On 21 January 2016 at 15:53, Haribabu Kommi wrote: > On Thu, Jan 21, 2016 at 1:33 PM, Haribabu Kommi > wrote: > > > > Here I attached updated patch of parallel aggregate based on the latest > > changes in master. Still it lack of cost

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

2016-01-20 Thread Amit Kapila
On Thu, Jan 21, 2016 at 3:07 AM, Alvaro Herrera wrote: > > So far as I can tell, there are three patches in flight here: > Yes, thats right. > * replication slot IO lwlocks > * ability of extensions to request tranches dynamically > * PGPROC > > The first one hasn't

Re: [HACKERS] Parallel Aggregate

2016-01-20 Thread Haribabu Kommi
On Thu, Dec 24, 2015 at 5:12 AM, Robert Haas wrote: > On Mon, Dec 21, 2015 at 6:38 PM, David Rowley > wrote: >> On 22 December 2015 at 04:16, Paul Ramsey wrote: >>> >>> Shouldn’t parallel aggregate come into play

Re: [HACKERS] Releasing in September

2016-01-20 Thread Michael Paquier
On Thu, Jan 21, 2016 at 2:30 PM, Peter Geoghegan wrote: > On Wed, Jan 20, 2016 at 8:23 PM, Michael Paquier > wrote: >> Another tool that we had better IMO put some efforts in porting >> into core is sqlsmith, which would actually be a complete rewrite

Re: [HACKERS] Batch update of indexes

2016-01-20 Thread konstantin knizhnik
On Jan 21, 2016, at 5:14 AM, Simon Riggs wrote: > On 20 January 2016 at 14:55, Konstantin Knizhnik > wrote: > Hi, > > Hi, I glad to see that you interested in that too. > I think this is a good feature and I think it will be very useful to have. > I have already

Re: [HACKERS] Batch update of indexes

2016-01-20 Thread Simon Riggs
On 20 January 2016 at 14:55, Konstantin Knizhnik wrote: > Hi, > > Hi, I glad to see that you interested in that too. >> I think this is a good feature and I think it will be very useful to have. >> I have already mentioned some related problems and possible

Re: [HACKERS] COPY (... tab completion

2016-01-20 Thread Peter Eisentraut
On 1/19/16 6:00 AM, Andreas Karlsson wrote: > On 01/19/2016 07:55 AM, Michael Paquier wrote: >> +/* If we have COPY BINARY, compelete with list of tables */ >> s/compelete/complete > > Fixed. > >> +else if (TailMatches2("COPY|\\copy", "(")) >> +COMPLETE_WITH_LIST7("SELECT",

Re: [HACKERS] ALTER TABLE behind-the-scenes effects' CONTEXT

2016-01-20 Thread Simon Riggs
On 5 January 2016 at 06:45, Simon Riggs wrote: > On 4 January 2016 at 20:44, Alvaro Herrera > wrote: > > >> Maybe >> there are more ALTER TABLE subcommands that should be setting something >> up? In cases where multiple subcommands are being

Re: [HACKERS] [PATCH] better systemd integration

2016-01-20 Thread Pavel Stehule
2016-01-21 3:33 GMT+01:00 Peter Eisentraut : > On 1/18/16 10:58 AM, Alvaro Herrera wrote: > > Peter Eisentraut wrote: > >> I have written a couple of patches to improve the integration of the > >> postgres daemon with systemd. > > > > Great. Is anything happening with these

Re: [HACKERS] Releasing in September

2016-01-20 Thread Michael Paquier
On Thu, Jan 21, 2016 at 1:32 PM, Michael Paquier wrote: > On Thu, Jan 21, 2016 at 12:59 AM, Bruce Momjian wrote: >> On Wed, Jan 20, 2016 at 10:55:07AM -0500, Robert Haas wrote: >>> On Wed, Jan 20, 2016 at 10:48 AM, Andres Freund

Re: [HACKERS] Releasing in September

2016-01-20 Thread Tom Lane
Michael Paquier writes: > On Thu, Jan 21, 2016 at 2:30 PM, Peter Geoghegan wrote: >> What benefit does porting sqlsmith for inclusion in core have? I can >> only think of costs, including those that you mentioned. > We have automatic buildfarm

Re: [HACKERS] [PATCH] better systemd integration

2016-01-20 Thread Peter Eisentraut
On 1/18/16 10:58 AM, Alvaro Herrera wrote: > Peter Eisentraut wrote: >> I have written a couple of patches to improve the integration of the >> postgres daemon with systemd. > > Great. Is anything happening with these patches, or? They've been > inactive for quite a while now. Well, they are

Re: [HACKERS] Combining Aggregates

2016-01-20 Thread Haribabu Kommi
On Thu, Jan 21, 2016 at 12:32 PM, David Rowley wrote: > On 21 January 2016 at 04:59, Robert Haas wrote: >> >> On Wed, Jan 20, 2016 at 7:53 AM, David Rowley >> wrote: >> > On 21 January 2016 at 01:44, Robert Haas

Re: [HACKERS] Spurious standby query cancellations

2016-01-20 Thread Simon Riggs
On 24 December 2015 at 20:15, Jeff Janes wrote: > On Wed, Dec 23, 2015 at 9:40 PM, Jeff Janes wrote: > > On Wed, Sep 23, 2015 at 11:33 PM, Jeff Janes > wrote: > >> > >> On further thought, neither do I. The attached patch

Re: [HACKERS] Releasing in September

2016-01-20 Thread Michael Paquier
On Thu, Jan 21, 2016 at 12:59 AM, Bruce Momjian wrote: > On Wed, Jan 20, 2016 at 10:55:07AM -0500, Robert Haas wrote: >> On Wed, Jan 20, 2016 at 10:48 AM, Andres Freund wrote: >> > I think this has very little to do with commitfest schedules, and much >> >

Re: [HACKERS] WIP patch to improve amvalidate functions

2016-01-20 Thread Alvaro Herrera
Tom Lane wrote: > I'm posting this now just in case anyone has some comments, or quibbles > about the overall intent. In particular, if anyone has an idea for a more > thorough missing-objects check on BRIN opfamilies, I would like to hear > it. The fact that there are two kinds of opfamilies

Re: [HACKERS] Combining Aggregates

2016-01-20 Thread Haribabu Kommi
On Thu, Jan 21, 2016 at 1:33 PM, Haribabu Kommi wrote: > > Here I attached updated patch of parallel aggregate based on the latest > changes in master. Still it lack of cost comparison of normal aggregate to > parallel aggregate because of difficulty. This cost

Re: [HACKERS] WIP patch to improve amvalidate functions

2016-01-20 Thread Tom Lane
Alvaro Herrera writes: > Tom Lane wrote: >> I'm posting this now just in case anyone has some comments, or quibbles >> about the overall intent. In particular, if anyone has an idea for a more >> thorough missing-objects check on BRIN opfamilies, I would like to hear >>

Re: [HACKERS] exposing pg_controldata and pg_config as functions

2016-01-20 Thread Michael Paquier
On Wed, Jan 20, 2016 at 2:32 AM, Joe Conway wrote: > The only things I know of still lacking is: > 1) Documentation > 2) Decision on REVOKE ... FROM PUBLIC Yep, regarding 2) I am the only one actually making noise to protect this information by default, against at least 2

Re: [HACKERS] Expanded Objects and Order By

2016-01-20 Thread Tom Lane
I wrote: > Paul Ramsey writes: >> Thank the Maker, it is reproduceable: returning an expanded header in >> the _in function is not appreciated in a very narrow number of cases. > Thanks for finding a test case! I'll check into it shortly. So the short answer is that

Re: [HACKERS] Releasing in September

2016-01-20 Thread Michael Paquier
On Thu, Jan 21, 2016 at 8:51 AM, Peter Geoghegan wrote: > On Wed, Jan 20, 2016 at 2:56 PM, Tom Lane wrote: >> As a concrete example, I recall that Heikki or someone had a tool for >> checking WAL replay by comparing master and slave disk contents. We >>

Re: [HACKERS] checkpointer continuous flushing

2016-01-20 Thread Amit Kapila
On Wed, Jan 20, 2016 at 9:07 PM, Andres Freund wrote: > > On 2016-01-20 12:16:24 -0300, Alvaro Herrera wrote: > > Andres Freund wrote: > > > > > The relevant thread is at > > >

Re: [HACKERS] Batch update of indexes

2016-01-20 Thread Simon Riggs
On 21 January 2016 at 06:41, konstantin knizhnik wrote: > Certainly for B-Tree we can organize insert buffer (or pending list) as > sorted array or also as a tree. > But in both case complexity of search in this buffer will be O(log(N)), > not O(1). > You are right;

Re: [HACKERS] Re: pglogical_output - a general purpose logical decoding output plugin

2016-01-20 Thread Craig Ringer
On 21 January 2016 at 06:23, Tomasz Rybak wrote: > > I reviewed more files: Thanks. Can you try to put more whitespace between items? It can be hard to follow at the moment. > pglogical_proto_native.c > > + pq_sendbyte(out, 'N'); /* column name

Re: [HACKERS] Batch update of indexes

2016-01-20 Thread Konstantin Knizhnik
Hi, Hi, I glad to see that you interested in that too. I think this is a good feature and I think it will be very useful to have. I have already mentioned some related problems and possible improvements in my presentation.

Re: [HACKERS] WIP: Failover Slots

2016-01-20 Thread Craig Ringer
On 20 January 2016 at 21:02, Craig Ringer wrote: > TL;DR: this doesn't work yet, working on it. > Nothing is logged on slot creation because ReplicationSlot->data.failover is never true. Once that's fixed by - for now - making all slots failover slots, there's a crash in

Re: [HACKERS] jsonb array-style subscription

2016-01-20 Thread Dmitry Dolgov
On 20 January 2016 at 02:14, Alvaro Herrera wrote: > Dmitry Dolgov wrote: > > > I've cleaned up the code, created a separate JsonbRef node (and there > are a > > lot of small changes because of that), abandoned an idea of "deep > nesting" > > of assignments (because it

Re: [HACKERS] PostgreSQL 9.5.0 regress tests fails with Python 3.5.0

2016-01-20 Thread Tom Lane
Pavel Stehule writes: > make check-world fails, > It is fixed in HEAD. BTW, I have now spun up a new buildfarm member "longfin", which is testing against Python 3.5.1 (except in the 9.1 branch, where that doesn't work). regards, tom lane --

Re: [HACKERS] Releasing in September

2016-01-20 Thread Robert Haas
On Wed, Jan 20, 2016 at 12:03 PM, Tom Lane wrote: > Robert Haas writes: >> But I'm not very sure that we're talking about the same set of people >> here. If we're going to go to a system where nobody's allowed to >> commit anything for the next release

Re: [HACKERS] Releasing in September

2016-01-20 Thread Robert Haas
On Wed, Jan 20, 2016 at 1:29 PM, Andres Freund wrote: > On 2016-01-20 13:13:29 -0500, Robert Haas wrote: >> (3) Andres's multixact reworks landed quite late and IMHO were not >> safe enough to back-patch, yet they needed to be in the release. In >> my view, the last major fix

Re: [HACKERS] Proposal for UPDATE: do not insert new tuple on heap if update does not change data

2016-01-20 Thread Tom Lane
Gasper Zejn writes: > I was wondering if PostgreSQL adds new tuple if data is not changed > when using UPDATE. It turns out it does add them and I think it might > be beneficial not to add a new tuple in this case, since it causes a > great deal of maintenance: updating

Re: [HACKERS] Releasing in September

2016-01-20 Thread Joshua D. Drake
On 01/20/2016 07:40 AM, Bruce Momjian wrote: Our current 9.5/9.6 timing looks more like the 8.X series of release dates. Everyone might be fine with that, but we had better be prepared for November-February major release dates going forward. Bruce, Thank you for bringing this up it is a

Re: [HACKERS] Releasing in September

2016-01-20 Thread Tom Lane
Magnus Hagander writes: > That's pretty much what I suggested :) > Except that we need to do it for the last one as well. With the only > exception that the last one might be a bit longer. But the fact is that the > recent of CFs *and* releases, we've taken the approach of

Re: [HACKERS] Releasing in September

2016-01-20 Thread Joshua D. Drake
On 01/20/2016 09:31 AM, Joel Jacobson wrote: On Wed, Jan 20, 2016 at 5:29 PM, Andres Freund wrote: I think one thing we should work on, is being absolutely religious about requiring, say, 2 reviews for every nontrivial contribution. We currently seem to have a

Re: [HACKERS] Releasing in September

2016-01-20 Thread Alvaro Herrera
Joshua D. Drake wrote: > 4. Submit a patch, review a patch. > > Don't review patches? Don't submit patches. Here's one area where the commitfest app could help the CFM. I would like to have a report that shows, for each person, the list of patches where they are author, and the list of patches

Re: [HACKERS] Releasing in September

2016-01-20 Thread Andres Freund
On 2016-01-20 19:00:05 +0100, Magnus Hagander wrote: > And you want the actual patches, and not just a count? I think the actual patches makes sense, because reviewing one 200KB patch obviously is something different than reviewing 3 onelinesrs. -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Releasing in September

2016-01-20 Thread Alvaro Herrera
Magnus Hagander wrote: > On Jan 20, 2016 18:57, "Alvaro Herrera" wrote: > > Here's one area where the commitfest app could help the CFM. I would > > like to have a report that shows, for each person, the list of patches > > where they are author, and the list of

Re: [HACKERS] Releasing in September

2016-01-20 Thread Andres Freund
On 2016-01-20 13:03:05 -0500, Tom Lane wrote: > I am not sure what exactly ought to be different about them [small > patches], but probably something should. I think for small patches, > we are using the CF app mostly to be sure things don't fall through > the cracks, but maybe we don't need the

Re: [HACKERS] Releasing in September

2016-01-20 Thread Magnus Hagander
On Jan 20, 2016 5:03 PM, "Andres Freund" wrote: > > On 2016-01-20 10:55:07 -0500, Robert Haas wrote: > > It's certainly true that we twiddled our thumbs quite a bit about > > getting 9.5 ready to ship. However, the old process where nobody > > could get anything committed for

Re: [HACKERS] Releasing in September

2016-01-20 Thread Tom Lane
Magnus Hagander writes: > On Jan 20, 2016 5:03 PM, "Andres Freund" wrote: >> FWIW, looking at the last few commitfests, aside heroic and >> unsustainable efforts by individual CF managers, I haven't noticed any >> effect of when fests started/stopped.

Re: [HACKERS] Releasing in September

2016-01-20 Thread Robert Haas
On Wed, Jan 20, 2016 at 11:19 AM, Tom Lane wrote: > I do not think commitfest length is the problem (though surely it's not > working as intended). What happened with 9.5 is we forked the 9.6 > development branch on June 30th, with the expectation of releasing in > September,

Re: [HACKERS] Releasing in September

2016-01-20 Thread Andres Freund
> I admit, I may have grabbed your comment out of an unrelated portion > of the thread. Ceterum censeo Carthaginem esse delendam. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Proposal for UPDATE: do not insert new tuple on heap if update does not change data

2016-01-20 Thread Kevin Grittner
On Wed, Jan 20, 2016 at 3:55 AM, Gasper Zejn wrote: > I was wondering if PostgreSQL adds new tuple if data is not changed > when using UPDATE. It turns out it does add them and I think it might > be beneficial not to add a new tuple in this case, since it causes a > great

Re: [HACKERS] Releasing in September

2016-01-20 Thread Alvaro Herrera
Magnus Hagander wrote: > Except that we need to do it for the last one as well. With the only > exception that the last one might be a bit longer. But the fact is that the > recent of CFs *and* releases, we've taken the approach of closing the CF > when everything in it is done or explicitly

Re: [HACKERS] Releasing in September

2016-01-20 Thread Joshua D. Drake
On 01/20/2016 09:48 AM, David E. Wheeler wrote: On Jan 20, 2016, at 9:42 AM, Joshua D. Drake wrote: 4. Submit a patch, review a patch. Don't review patches? Don't submit patches. There will always be patches desirable-enough that they will be reviewed whether or

Re: [HACKERS] Releasing in September

2016-01-20 Thread Joel Jacobson
On Wed, Jan 20, 2016 at 5:29 PM, Andres Freund wrote: > I think one thing we should work on, is being absolutely religious about > requiring, say, 2 reviews for every nontrivial contribution. We > currently seem to have a significantly increased submission rate, and at > the

Re: [HACKERS] Releasing in September

2016-01-20 Thread Andres Freund
On 2016-01-20 09:48:24 -0800, David E. Wheeler wrote: > There will always be patches desirable-enough that they will be reviewed > whether or not the submitter reviewed other patches. I think that's actually getting less and less true. By now the really desirable-enough features imply so much

Re: [HACKERS] custom function for converting human readable sizes to bytes

2016-01-20 Thread Pavel Stehule
2016-01-19 4:45 GMT+01:00 Vitaly Burovoy : > On 1/4/16, Pavel Stehule wrote: > > 2016-01-04 18:13 GMT+01:00 Shulgin, Oleksandr < > oleksandr.shul...@zalando.de> : > >> On Mon, Jan 4, 2016 at 6:03 PM, Pavel Stehule >

Re: [HACKERS] Releasing in September

2016-01-20 Thread Simon Riggs
On 20 January 2016 at 15:40, Bruce Momjian wrote: > Many people where happy with our consistent releasing major releases in > September, e.g. 9.0 to 9.3: > What is the point in having a special mailing list to discuss the release schedule plus a face-to-face dev meeting to

Re: [HACKERS] Releasing in September

2016-01-20 Thread Andres Freund
On 2016-01-20 10:40:14 -0500, Bruce Momjian wrote: > We have gotten off of that cycle in the last two major releases, and > this isn't going to improve as long as we have commitfests starting > after January. I think this has very little to do with commitfest schedules, and much more with the

Re: [HACKERS] Releasing in September

2016-01-20 Thread Robert Haas
On Wed, Jan 20, 2016 at 10:48 AM, Andres Freund wrote: > On 2016-01-20 10:40:14 -0500, Bruce Momjian wrote: >> We have gotten off of that cycle in the last two major releases, and >> this isn't going to improve as long as we have commitfests starting >> after January. > > I

Re: [HACKERS] Releasing in September

2016-01-20 Thread Joshua D. Drake
On 01/20/2016 09:17 AM, Andres Freund wrote: On 2016-01-20 09:15:01 -0800, Joshua D. Drake wrote: On 01/20/2016 09:03 AM, Andres Freund wrote: If people don't fix the issues in time, there needs to be direct pushback, leading to much less stuff getting in next time round. We have been

Re: [HACKERS] Proposal for UPDATE: do not insert new tuple on heap if update does not change data

2016-01-20 Thread Konstantin Knizhnik
Hi, To eliminate creation of new tuple version in this case it is necessary to check that update actually doesn't change the record. It is not a cheapest test and it seems to be not so good idea to perform it always. But if you fill that in your case there are many "identical" updates, you

Re: [HACKERS] Releasing in September

2016-01-20 Thread Bruce Momjian
On Wed, Jan 20, 2016 at 07:53:25AM -0800, Joshua Drake wrote: > #2 This is a longer topic. I have been stewing in my head about > releases for years. I have even brought up the idea of an Ubuntu > style release cycle on list once or twice. The more I think about > it, the more I think this can

Re: [HACKERS] Releasing in September

2016-01-20 Thread Andres Freund
On 2016-01-20 09:15:01 -0800, Joshua D. Drake wrote: > On 01/20/2016 09:03 AM, Andres Freund wrote: > >If people don't fix the issues in time, there needs to be > >direct pushback, leading to much less stuff getting in next time round. > > > > We have been slowly moving to a more dictator based

Re: [HACKERS] checkpointer continuous flushing

2016-01-20 Thread Alvaro Herrera
Andres Freund wrote: > The relevant thread is at > http://archives.postgresql.org/message-id/CA%2BTgmoaCr3kDPafK5ygYDA9mF9zhObGp_13q0XwkEWsScw6h%3Dw%40mail.gmail.com > what I didn't remember is that I voiced concern back then about exactly this: >

[HACKERS] Releasing in September

2016-01-20 Thread Bruce Momjian
Many people where happy with our consistent releasing major releases in September, e.g. 9.0 to 9.3: 9.5 2016-01-07 9.4 2014-12-18 9.3 2013-09-09 <-- 9.2 2012-09-10 <-- 9.1 2011-09-12 <-- 9.0 2010-09-20 <-- 8.4 2009-07-01

Re: [HACKERS] Releasing in September

2016-01-20 Thread Bruce Momjian
On Wed, Jan 20, 2016 at 11:53:32AM -0500, Robert Haas wrote: > On Wed, Jan 20, 2016 at 11:19 AM, Tom Lane wrote: > > I do not think commitfest length is the problem (though surely it's not > > working as intended). What happened with 9.5 is we forked the 9.6 > > development

Re: [HACKERS] Releasing in September

2016-01-20 Thread Andres Freund
On 2016-01-20 11:53:32 -0500, Robert Haas wrote: > But I'm not very sure that we're talking about the same set of people > here. If we're going to go to a system where nobody's allowed to > commit anything for the next release until the current release is > finalized, then we'd better have some

Re: [HACKERS] Releasing in September

2016-01-20 Thread Tom Lane
Robert Haas writes: > But I'm not very sure that we're talking about the same set of people > here. If we're going to go to a system where nobody's allowed to > commit anything for the next release until the current release is > finalized, then we'd better have some

Re: [HACKERS] Releasing in September

2016-01-20 Thread Tom Lane
Magnus Hagander writes: > On Wed, Jan 20, 2016 at 5:19 PM, Tom Lane wrote: >> I do not think commitfest length is the problem (though surely it's not >> working as intended). What happened with 9.5 is we forked the 9.6 > I agree that it's not the same

Re: [HACKERS] Releasing in September

2016-01-20 Thread Andres Freund
On 2016-01-20 12:18:28 -0500, Tom Lane wrote: > I'm not really sure why we've allowed CFs to drift on, though. Can't we > just arbitrarily decree them closed on the last day of the month? And > push unfinished work to the next one? Admittedly, this probably doesn't > work for the last CF of a

Re: [HACKERS] Releasing in September

2016-01-20 Thread Magnus Hagander
On Wed, Jan 20, 2016 at 6:18 PM, Tom Lane wrote: > Magnus Hagander writes: > > On Wed, Jan 20, 2016 at 5:19 PM, Tom Lane wrote: > >> I do not think commitfest length is the problem (though surely it's not > >> working as intended).

Re: [HACKERS] checkpointer continuous flushing

2016-01-20 Thread Andres Freund
On 2016-01-20 12:16:24 -0300, Alvaro Herrera wrote: > Andres Freund wrote: > > > The relevant thread is at > > http://archives.postgresql.org/message-id/CA%2BTgmoaCr3kDPafK5ygYDA9mF9zhObGp_13q0XwkEWsScw6h%3Dw%40mail.gmail.com > > what I didn't remember is that I voiced concern back then about

Re: [HACKERS] Releasing in September

2016-01-20 Thread Joshua D. Drake
On 01/20/2016 09:03 AM, Andres Freund wrote: If people don't fix the issues in time, there needs to be direct pushback, leading to much less stuff getting in next time round. We have been slowly moving to a more dictator based release anyway. It used to be that we released "when it's done",

Re: [HACKERS] Set search_path + server-prepared statements = cached plan must not change result type

2016-01-20 Thread Vladimir Sitnikov
> I believe, and the conclusion was that >if you think you need this, you're doing it wrong So what is the recommended approach to use server-prepared statements at the client side (I mean at JDBC driver side)? Currently "prepare, switch search_path, execute" leads to "cached plan must not

Re: [HACKERS] Combining Aggregates

2016-01-20 Thread Robert Haas
On Wed, Jan 20, 2016 at 7:53 AM, David Rowley wrote: > On 21 January 2016 at 01:44, Robert Haas wrote: >> >> On Wed, Jan 20, 2016 at 7:38 AM, David Rowley >> wrote: >> >> To my mind, priority #1 ought to be

Re: [HACKERS] Releasing in September

2016-01-20 Thread Bruce Momjian
On Wed, Jan 20, 2016 at 10:55:07AM -0500, Robert Haas wrote: > On Wed, Jan 20, 2016 at 10:48 AM, Andres Freund wrote: > > I think this has very little to do with commitfest schedules, and much > > more with the "early" forking of the new version branch. For both 9.4 > > and

Re: [HACKERS] custom function for converting human readable sizes to bytes

2016-01-20 Thread Pavel Stehule
Hi 2016-01-19 0:56 GMT+01:00 Vitaly Burovoy : > On 1/4/16, Robert Haas wrote: > > On Mon, Jan 4, 2016 at 10:17 AM, Pavel Stehule > > wrote: > >> [ new patch ] > > > > + case '-': > > + ereport(ERROR,

Re: [HACKERS] Releasing in September

2016-01-20 Thread Joshua D. Drake
On 01/20/2016 08:51 AM, Bruce Momjian wrote: On Wed, Jan 20, 2016 at 07:53:25AM -0800, Joshua Drake wrote: #2 This is a longer topic. I have been stewing in my head about releases for years. I have even brought up the idea of an Ubuntu style release cycle on list once or twice. The more I think

Re: [HACKERS] Releasing in September

2016-01-20 Thread Magnus Hagander
On Wed, Jan 20, 2016 at 5:19 PM, Tom Lane wrote: > Magnus Hagander writes: > > On Jan 20, 2016 5:03 PM, "Andres Freund" wrote: > >> FWIW, looking at the last few commitfests, aside heroic and > >> unsustainable efforts by individual

Re: [HACKERS] Releasing in September

2016-01-20 Thread Andres Freund
On 2016-01-20 10:55:07 -0500, Robert Haas wrote: > It's certainly true that we twiddled our thumbs quite a bit about > getting 9.5 ready to ship. However, the old process where nobody > could get anything committed for six months out of the year blew > chunks, too. Personally, I think that the

Re: [HACKERS] Releasing in September

2016-01-20 Thread Andres Freund
On 2016-01-20 11:19:28 -0500, Tom Lane wrote: > We will not get back to on-schedule releases unless we can keep -hackers > working on release testing/stabilization when it's time to do that, > rather than being distracted by shiny new stuff going into the next > release. Agreed. I'll note that

Re: [HACKERS] Releasing in September

2016-01-20 Thread Simon Riggs
On 20 January 2016 at 15:55, Robert Haas wrote: > On Wed, Jan 20, 2016 at 10:48 AM, Andres Freund > wrote: > > On 2016-01-20 10:40:14 -0500, Bruce Momjian wrote: > >> We have gotten off of that cycle in the last two major releases, and > >> this isn't

Re: [HACKERS] multivariate statistics v8

2016-01-20 Thread Robert Haas
On Wed, Dec 23, 2015 at 2:07 PM, Tomas Vondra wrote: >The remaining question is how unique the statistics name should be. >My initial plan was to make it unique within a table, but that of >course does not work well with the DROP STATISTICS (it'd have to

Re: [HACKERS] Releasing in September

2016-01-20 Thread Simon Riggs
On 20 January 2016 at 19:45, Robert Haas wrote: > On Wed, Jan 20, 2016 at 2:26 PM, Tom Lane wrote: > > and...@anarazel.de (Andres Freund) writes: > >> On 2016-01-20 18:53:54 +, Simon Riggs wrote: > >>> What is the point in having a special mailing

Re: Odd behavior in foreign table modification (Was: Re: [HACKERS] Optimization for updating foreign tables in Postgres FDW)

2016-01-20 Thread Robert Haas
On Wed, Jan 20, 2016 at 4:50 AM, Etsuro Fujita wrote: > My concern about that is that would make the code in deparseTargetList() > complicated. > > Essentially, I think your propossal needs a two-pass algorithm for > deparseTargetList; (1) create an integer List of

Re: [HACKERS] Combining Aggregates

2016-01-20 Thread Robert Haas
On Wed, Jan 20, 2016 at 7:38 AM, David Rowley wrote: > Agreed. So I've attached a version of the patch which does not have any of > the serialise/deserialise stuff in it. I re-reviewed this and have committed most of it with only minor kibitizing. A few notes: - I

Re: [HACKERS] Releasing in September

2016-01-20 Thread Tom Lane
and...@anarazel.de (Andres Freund) writes: > On 2016-01-20 18:53:54 +, Simon Riggs wrote: >> What is the point in having a special mailing list to discuss the release >> schedule plus a face-to-face dev meeting to discuss this if we are going to >> discuss it here? > That list exists to

Re: [HACKERS] Releasing in September

2016-01-20 Thread Peter Geoghegan
On Wed, Jan 20, 2016 at 11:13 AM, Andres Freund wrote: > That list exists to discuss concrete releases, and is separate so we > e.g. can mention there's security issues and such. This topic in > contrast quite validly merits input from more then the usual suspects > going to a

Re: [HACKERS] Releasing in September

2016-01-20 Thread Andres Freund
On 2016-01-20 18:53:54 +, Simon Riggs wrote: > What is the point in having a special mailing list to discuss the release > schedule plus a face-to-face dev meeting to discuss this if we are going to > discuss it here? That list exists to discuss concrete releases, and is separate so we e.g.

Re: [HACKERS] Releasing in September

2016-01-20 Thread Simon Riggs
On 20 January 2016 at 16:29, Andres Freund wrote: > I think one thing we should work on, is being absolutely religious about > requiring, say, 2 reviews for every nontrivial contribution. We > currently seem to have a significantly increased submission rate, and at > the

Re: [HACKERS] Releasing in September

2016-01-20 Thread Simon Riggs
On 20 January 2016 at 15:40, Bruce Momjian wrote: > Many people were happy with our consistent releasing major releases in > September, e.g. 9.0 to 9.3: > > 9.5 2016-01-07 > 9.4 2014-12-18 > 9.3 2013-09-09 <-- > 9.2 2012-09-10 <-- >

Re: [HACKERS] Releasing in September

2016-01-20 Thread Gavin Flower
On 21/01/16 06:40, Tom Lane wrote: Magnus Hagander writes: That's pretty much what I suggested :) Except that we need to do it for the last one as well. With the only exception that the last one might be a bit longer. But the fact is that the recent of CFs *and* releases,

Re: [HACKERS] Releasing in September

2016-01-20 Thread Simon Riggs
On 20 January 2016 at 17:03, Tom Lane wrote: > Robert Haas writes: > > But I'm not very sure that we're talking about the same set of people > > here. If we're going to go to a system where nobody's allowed to > > commit anything for the next release

Re: [HACKERS] Releasing in September

2016-01-20 Thread Robert Haas
On Wed, Jan 20, 2016 at 2:26 PM, Tom Lane wrote: > and...@anarazel.de (Andres Freund) writes: >> On 2016-01-20 18:53:54 +, Simon Riggs wrote: >>> What is the point in having a special mailing list to discuss the release >>> schedule plus a face-to-face dev meeting to

Re: [HACKERS] Fuzzy substring searching with the pg_trgm extension

2016-01-20 Thread Alvaro Herrera
Artur Zakirov wrote: > >I don't quite understand why aren't we using a custom GUC variable here. > >These already have SHOW and SET support ... > > > > Added GUC variables: > - pg_trgm.limit > - pg_trgm.substring_limit > I added this variables to the documentation. > show_limit() and set_limit()

Re: [HACKERS] postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs)

2016-01-20 Thread Robert Haas
On Mon, Jan 18, 2016 at 6:47 AM, Ashutosh Bapat wrote: > 2. pg_fdw_join_v2.patch: postgres_fdw changes for supporting join pushdown The very first hunk of this patch contains annoying whitespace changes. Even if the result is what pgindent is going to do anyway,

Re: [HACKERS] Releasing in September

2016-01-20 Thread Joshua D. Drake
On 01/20/2016 10:53 AM, Simon Riggs wrote: On 20 January 2016 at 15:40, Bruce Momjian > wrote: Many people where happy with our consistent releasing major releases in September, e.g. 9.0 to 9.3: What is the point in having a special mailing

Re: [HACKERS] Releasing in September

2016-01-20 Thread Magnus Hagander
On Wed, Jan 20, 2016 at 6:57 PM, Alvaro Herrera wrote: > Joshua D. Drake wrote: > > > 4. Submit a patch, review a patch. > > > > Don't review patches? Don't submit patches. > > Here's one area where the commitfest app could help the CFM. I would > like to have a report

Re: [HACKERS] postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs)

2016-01-20 Thread Robert Haas
On Wed, Jan 20, 2016 at 8:53 AM, Ashutosh Bapat wrote: > I missed the example plan cache revalidation patch in the previous mail. > Sorry. Here it is. I see. Yeah, I don't see a reason offhand why that wouldn't work. But you need to update src/backend/nodes for

Re: [HACKERS] Why format() adds double quote?

2016-01-20 Thread Robert Haas
On Wed, Jan 20, 2016 at 4:20 AM, Pavel Stehule wrote: >> If we would go this way, question is if we should back patch this or >> not since the patch apparently changes the existing >> behaviors. Comments? I would think we should not. > > I am sure, so we should not

Re: [HACKERS] postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs)

2016-01-20 Thread Robert Haas
On Wed, Jan 20, 2016 at 8:50 AM, Ashutosh Bapat wrote: >> Third, I removed GetUserMappingById(). As mentioned in the email to >> which I replied earlier, that doesn't actually produce the same result >> as the way we're doing it now, and might leave the user ID

Re: [HACKERS] Releasing in September

2016-01-20 Thread Simon Riggs
On 20 January 2016 at 20:29, Joshua D. Drake wrote: > On 01/20/2016 10:53 AM, Simon Riggs wrote: > >> On 20 January 2016 at 15:40, Bruce Momjian > > wrote: >> >> Many people where happy with our consistent releasing major

  1   2   >