Re: [HACKERS] Releasing in September

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

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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> 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

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

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

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

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

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

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

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

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

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

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)

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

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

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

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

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

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

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

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

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

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)

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

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

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)

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?

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)

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

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

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

W dniu 20.01.2016, śro o godzinie 13∶54 +0800, użytkownik Craig Ringer napisał: > On 20 January 2016 at 06:23, Tomasz Rybak > wrote: > > The following review has been posted through the commitfest > > application: > > > Thanks! >   > >   > > + /* Protocol capabilities */ >

  1   2   >