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

Hi, There's a not so well known issue of "set search_path" and "server-prepared statement" usage. In short, it does not always work. See more details in [1]. There issue has reproduced once again recently (see [2], that explains that search_path is modified for a multi-tenant setup). Even though

Re: [HACKERS] Inconsistent error handling in START_REPLICATION command

On 20 January 2016 at 15:28, Craig Ringer wrote: > > For that reason I'd actually like to enter COPY BOTH mode before the > startup callback, as is currently the case. So I'd like to wrap the > decoding startup callback in a PG_TRY that catches an ERROR raised by the > startup callback (if any) a

Re: [HACKERS] Stream consistent snapshot via a logical decoding plugin as a series of INSERTs

On 20 January 2016 at 15:50, Shulgin, Oleksandr < oleksandr.shul...@zalando.de> wrote: > All of this implies another *postgres* database on the receiving side, > which is not necessarily the case for my research. > Good point. It might not be a DB at all, either, i.e. it might not understand INS

Re: [HACKERS] Stream consistent snapshot via a logical decoding plugin as a series of INSERTs

On Wed, Jan 20, 2016 at 9:26 AM, Craig Ringer wrote: > On 20 January 2016 at 15:50, Shulgin, Oleksandr < > oleksandr.shul...@zalando.de> wrote: > > That'd be nice, but probably not totally necessary for streaming > relations. It doesn't really need the slot at all. Or shouldn't, I think. > Though

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

> Hi > > 2016-01-20 7:20 GMT+01:00 Tatsuo Ishii : > >> > 2016-01-20 3:47 GMT+01:00 Tatsuo Ishii : >> > >> >> test=# select format('%I', t) from t1; >> >> format >> >> -- >> >> aaa >> >> "AAA" >> >> "あいう" >> >> (3 rows) >> >> >> >> Why is the text value of the third line needed to be

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

2016-01-20 10:17 GMT+01:00 Tatsuo Ishii : > > Hi > > > > 2016-01-20 7:20 GMT+01:00 Tatsuo Ishii : > > > >> > 2016-01-20 3:47 GMT+01:00 Tatsuo Ishii : > >> > > >> >> test=# select format('%I', t) from t1; > >> >> format > >> >> -- > >> >> aaa > >> >> "AAA" > >> >> "あいう" > >> >> (3 rows

[HACKERS] Batch update of indexes

Hi hackers, I want to know opinion of community about possible ways of solving quite common problem: increasing insert speed while still providing indexes for efficient execution of queries. Many applications have to deal with high input stream of data. Most of the time while record insertin

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

On 2016/01/20 3:42, Robert Haas wrote: On Tue, Jan 19, 2016 at 1:59 AM, Etsuro Fujita wrote: I've run into an issue: *# UPDATE master_customers SET id = 22 WHERE id = 16 RETURNING tableoid::regclass; ERROR: CONTEXT: Remote SQL command: UPDATE public.customers SET id = 22 WHERE ((id = 16)) RET

Re: [HACKERS] checkpointer continuous flushing

On 2016-01-19 22:43:21 +0100, Andres Freund wrote: > On 2016-01-19 12:58:38 -0500, Robert Haas wrote: > > This seems like a problem with the WAL writer quite independent of > > anything else. It seems likely to be inadvertent fallout from this > > patch: > > > > Author: Simon Riggs > > Branch: m

Re: [HACKERS] Optimization for updating foreign tables in Postgres FDW

On Fri, Jan 15, 2016 at 9:06 AM, Etsuro Fujita wrote: > On 2016/01/14 21:36, Rushabh Lathia wrote: > >> On Thu, Jan 14, 2016 at 2:00 PM, Etsuro Fujita >> mailto:fujita.ets...@lab.ntt.co.jp>> wrote: >> > > On 2016/01/12 20:31, Rushabh Lathia wrote: >> > > On Thu, Jan 7, 2016 at 6:15 PM

Re: [HACKERS] dynloader.h missing in prebuilt package for Windows?

On Wed, Jan 20, 2016 at 1:37 PM, Michael Paquier wrote: > On Wed, Jan 20, 2016 at 1:34 PM, Bruce Momjian wrote: >> On Mon, Jan 4, 2016 at 09:50:40PM -0800, Michael Paquier wrote: >>> On Tue, Jan 5, 2016 at 2:27 PM, Tom Lane wrote: >>> > Michael Paquier writes: >>> >> The patch would put the bu

Re: [HACKERS] Combining Aggregates

On 20 January 2016 at 10:54, Robert Haas wrote: > On Tue, Jan 19, 2016 at 4:50 PM, David Rowley > wrote: > >> Oh, one more point: is there any reason why all of this needs to be a > >> single (giant) patch? I feel like the handling of internal states > >> could be a separate patch from the basi

Re: [HACKERS] Combining Aggregates

On Wed, Jan 20, 2016 at 7:38 AM, David Rowley wrote: >> To my mind, priority #1 ought to be putting this fine new >> functionality to some use. Expanding it to every aggregate we've got >> seems like a distinctly second priority. That's not to say that it's >> absolutely gotta go down that way,

Re: [HACKERS] Combining Aggregates

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 putting this fine new > >> functionality to some use. Expanding it to every aggregate we've got > >> seems like a distinctly second priority. That's

Re: [HACKERS] WIP: Failover Slots

On 2 January 2016 at 08:50, Simon Riggs wrote: > Patch is WIP, posted for comment, so you can see where I'm going. > I've applied this on a branch of master and posted it, with some comment editorialization, as https://github.com/2ndQuadrant/postgres/tree/dev/failover-slots . The tree will be

Re: [HACKERS] RFC: replace pg_stat_activity.waiting with something more descriptive

On Tue, Jan 19, 2016 at 11:49 PM, Amit Kapila wrote: >> My opinion is that storing the information in PGPROC is better because >> it seems like we can fairly painlessly expose 4 bytes of data that way >> instead of 1, which is nice. > > Okay, do you mean to say that we can place this new 4-byte va

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

On Wed, Jan 20, 2016 at 4:58 AM, Robert Haas wrote: > On Mon, Jan 18, 2016 at 6:47 AM, Ashutosh Bapat > wrote: > > Thanks Thom for bringing it to my notice quickly. Sorry for the same. > > > > Here are the patches. > > > > 1. pg_fdw_core_v2.patch: changes in core related to user mapping > handli

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

I missed the example plan cache revalidation patch in the previous mail. Sorry. Here it is. On Wed, Jan 20, 2016 at 7:20 PM, Ashutosh Bapat < ashutosh.ba...@enterprisedb.com> wrote: > > > On Wed, Jan 20, 2016 at 4:58 AM, Robert Haas > wrote: > >> On Mon, Jan 18, 2016 at 6:47 AM, Ashutosh Bapat >

Re: [HACKERS] checkpointer continuous flushing

On 2016-01-20 11:13:26 +0100, Andres Freund wrote: > On 2016-01-19 22:43:21 +0100, Andres Freund wrote: > > On 2016-01-19 12:58:38 -0500, Robert Haas wrote: > > I think the problem isn't really that it's flushing too much WAL in > > total, it's that it's flushing WAL in a too granular fashion. I su

Re: [HACKERS] GIN pending list clean up exposure to SQL

On Sat, Jan 16, 2016 at 7:42 AM, Julien Rouhaud wrote: > On 15/01/2016 22:59, Jeff Janes wrote: >> On Sun, Jan 10, 2016 at 4:24 AM, Julien Rouhaud >> wrote: >>> On 29/12/2015 00:30, Jeff Janes wrote: On Wed, Nov 25, 2015 at 9:29 AM, Jeff Janes wrote: > > I'll prepare a patch for cor

Re: [HACKERS] Batch update of indexes

20.01.2016 12:28, Konstantin Knizhnik : Hi hackers, I want to know opinion of community about possible ways of solving quite common problem: increasing insert speed while still providing indexes for efficient execution of queries. Many applications have to deal with high input stream of data

[HACKERS] removal of unused argument in ginInsertCleanup()

Hi, I found the unused argument "vac_delay" in ginInsertCleanup(). I think that we should remove it. Patch attached. Regards, -- Fujii Masao *** a/src/backend/access/gin/ginfast.c --- b/src/backend/access/gin/ginfast.c *** *** 434,440 ginHeapTupleFastInsert(GinState *ginstate,

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

Hi, 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 indexes, vacuuming table and index, also heap fragm

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

Vladimir Sitnikov writes: > Here's my question: why change in search_path does NOT generate > ParameterStatus message from the backend? The protocol specification includes a list of the small number of GUCs for which ParameterStatus messages are generated, and that is not one of them. This has b

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. http://www.slideshare.net/AnastasiaLubennikova/indexes-dont-mean-slow-i

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 XLogInsert because of t

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: > http://archives.postgresql.org/message-id/20111201

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 can

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 chang

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 exac

[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] 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 indexes, vacuuming table an

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

Re: [HACKERS] Releasing in September

On Wed, Jan 20, 2016 at 04:48:16PM +0100, 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 think this h

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 good

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 think this has very lit

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 9.5 we essentially spen

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 putting this fine new >> >> functionality to some use. Expanding it to every aggregate w

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 so

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 six months out of th

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, > > + (errcode(ERRCODE_INVALID_PARAMETER_VALUE), > > +

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. Aside from a short time increase >> in unfini

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 the

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 help

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, and then couldn't re

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 branch on June 30th, w

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 pr

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 procedure for making sure that

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 CF managers, I haven't noticed any > >> effect of when fests s

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", t

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

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 problem. I do believe that it is *a* proble

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 slowly

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

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). What happened with 9.5 is we forked the 9.6 > > > I agree that

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 deal of maintenance: upd

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 same time the number

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 closing the CF > when e

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 significantly increased submissio

Re: [HACKERS] Releasing in September

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 not the submitter reviewed other patches. And there will often be patche

Re: [HACKERS] Releasing in September

On 2016-01-20 09:42:28 -0800, Joshua D. Drake wrote: > Don't review patches? Don't submit patches. Absolutely. While I think encouraging reviewers is a good thing, it seems independent of requiring contributors to do quid-pro-quo reviews. There'll always be people too busy or uninterested in revie

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 -- Sent via pgsql-hackers maili

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 doesn't relate to jsonb sub

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 revie

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 wor

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 not the submitter reviewed

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 Jan 20, 2016 18:57, "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 that shows, for each person, the

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 patches where they are reviewer.

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 (pgsql-hac

Re: [HACKERS] Releasing in September

Andres Freund writes: > 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-en

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 until the current release is >> finalized,

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 w

Re: [HACKERS] Releasing in September

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 for At least in that case I was, for a long while, basically hoping for more in

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 for > > At least in

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 > wrote: > >> > 2016-01-04 17:48 GMT+01:00 Shulgin, Oleksandr < > oleksandr.shul..

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 discuss this if we are

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 going to improve as long as we have commitfe

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 same time the number 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 changed the EXPLAIN code, sinc

Re: [HACKERS] Releasing in September

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 until the current release is > > finalized,

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

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 >specify the table name als

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 discus

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 developer meeting.

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 discuss this if we are goi

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 <-- > 9.1 2011-09-12

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 list to discuss the > release > >>> schedule

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, we've taken the approa

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 the columns being retrieved > fr

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 the new field in each place where

Re: [HACKERS] Releasing in September

On 01/20/2016 10:53 AM, Simon Riggs wrote: On 20 January 2016 at 15:40, Bruce Momjian mailto:br...@momjian.us>> 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 r

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 invalid. > > The comment you quoted

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 backport this change. This can

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 releases >> in >> September, e.g. 9.0 to 9

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 */ > > + #define PGLOGICAL_P

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] 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 that shows, for each perso

  1   2   >