Re: [HACKERS] Closing commitfest 2013-11
Alvaro Herrera wrote: > With apologies to our beloved commitfest-mace-wielding CFM, commitfest > 2013-11 intentionally still contains a few open patches. I think that > CF is largely being ignored by most people now that we have CF 2014-01 > in progress. If we don't want to do anything about these patches in the > immediate future, I propose we move them to CF 2014-01. > > * shared memory message queues I closed this one as committed. > * Shave a few instructions from child-process startup sequence > * Widening application of indices. I marked these as returned with feedback. > * fault tolerant DROP IF EXISTS Committed this one and marked as such. > * SSL: better default ciphersuite This one was moved to 2014-01 (not by me). So there is nothing remaining in 2013-11 and we can (continue to) focus exclusively on 2014-01. Yay! -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- 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] Closing commitfest 2013-11
Vik Fearing wrote: > On 01/20/2014 10:31 PM, Tom Lane wrote: > > I think the idea was that patch authors should take responsibility for > > pushing their patches forward to 2014-01 if they still wanted them > > considered. Quite a few patches already were moved that way, IIRC. > > > > Agreed though that we shouldn't let them just rot. > > Does this mean I can resurrect my pg_sleep_until() patch? I didn't set > it back to Needs Review after I completely changed my approach based on > feedback. I would hate for it to get lost just because I didn't know > how to use the commitfest app. > > https://commitfest.postgresql.org/action/patch_view?id=1189 No objection here. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- 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] Closing commitfest 2013-11
On 01/20/2014 10:31 PM, Tom Lane wrote: > I think the idea was that patch authors should take responsibility for > pushing their patches forward to 2014-01 if they still wanted them > considered. Quite a few patches already were moved that way, IIRC. > > Agreed though that we shouldn't let them just rot. Does this mean I can resurrect my pg_sleep_until() patch? I didn't set it back to Needs Review after I completely changed my approach based on feedback. I would hate for it to get lost just because I didn't know how to use the commitfest app. https://commitfest.postgresql.org/action/patch_view?id=1189 -- Vik -- 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] Closing commitfest 2013-11
Dne 21.1.2014 18:52 "Pavel Stehule" napsal(a): > > Hello > > I disagree with it. There was no any request to move "ready for commit" patches to next commitfest! I expected so only unfinishing patches should by moved there by their authors. I sent question to Peter E. But without reply, but Tom did commits from thist list, so I expected so there is some agreement about it and I did'nt any alarm. > > My patch there is prerequsity for "dump --if-exi Sorry, train and mobile :( It is required for "dump --if-exists" feature. Regards Pavel > > Dne 21.1.2014 17:41 "Robert Haas" napsal(a): > >> On Mon, Jan 20, 2014 at 4:31 PM, Tom Lane wrote: >> > Alvaro Herrera writes: >> >> With apologies to our beloved commitfest-mace-wielding CFM, commitfest >> >> 2013-11 intentionally still contains a few open patches. I think that >> >> CF is largely being ignored by most people now that we have CF 2014-01 >> >> in progress. If we don't want to do anything about these patches in the >> >> immediate future, I propose we move them to CF 2014-01. >> > >> > I think the idea was that patch authors should take responsibility for >> > pushing their patches forward to 2014-01 if they still wanted them >> > considered. Quite a few patches already were moved that way, IIRC. >> >> Agreed on that general theory. >> >> And, also, yeah, the shared memory message queueing stuff got >> committed. Sorry, I missed the fact that there was still an open CF >> entry for that; I assumed that it would have been marked Returned with >> Feedback. >> >> -- >> Robert Haas >> EnterpriseDB: http://www.enterprisedb.com >> The Enterprise PostgreSQL Company >> >> >> -- >> 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] Closing commitfest 2013-11
Hello I disagree with it. There was no any request to move "ready for commit" patches to next commitfest! I expected so only unfinishing patches should by moved there by their authors. I sent question to Peter E. But without reply, but Tom did commits from thist list, so I expected so there is some agreement about it and I did'nt any alarm. My patch there is prerequsity for "dump --if-exi Dne 21.1.2014 17:41 "Robert Haas" napsal(a): > On Mon, Jan 20, 2014 at 4:31 PM, Tom Lane wrote: > > Alvaro Herrera writes: > >> With apologies to our beloved commitfest-mace-wielding CFM, commitfest > >> 2013-11 intentionally still contains a few open patches. I think that > >> CF is largely being ignored by most people now that we have CF 2014-01 > >> in progress. If we don't want to do anything about these patches in the > >> immediate future, I propose we move them to CF 2014-01. > > > > I think the idea was that patch authors should take responsibility for > > pushing their patches forward to 2014-01 if they still wanted them > > considered. Quite a few patches already were moved that way, IIRC. > > Agreed on that general theory. > > And, also, yeah, the shared memory message queueing stuff got > committed. Sorry, I missed the fact that there was still an open CF > entry for that; I assumed that it would have been marked Returned with > Feedback. > > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > > > -- > 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] Closing commitfest 2013-11
On Mon, Jan 20, 2014 at 4:31 PM, Tom Lane wrote: > Alvaro Herrera writes: >> With apologies to our beloved commitfest-mace-wielding CFM, commitfest >> 2013-11 intentionally still contains a few open patches. I think that >> CF is largely being ignored by most people now that we have CF 2014-01 >> in progress. If we don't want to do anything about these patches in the >> immediate future, I propose we move them to CF 2014-01. > > I think the idea was that patch authors should take responsibility for > pushing their patches forward to 2014-01 if they still wanted them > considered. Quite a few patches already were moved that way, IIRC. Agreed on that general theory. And, also, yeah, the shared memory message queueing stuff got committed. Sorry, I missed the fact that there was still an open CF entry for that; I assumed that it would have been marked Returned with Feedback. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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] Closing commitfest 2013-11
On 20 January 2014 21:24, Alvaro Herrera wrote: > * fault tolerant DROP IF EXISTS > I gave a look and it looks good for application. This wasn't > superceded by a future version, correct? > No, this hasn't been superceded. +1 for applying it. Regards, Dean -- 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] Closing commitfest 2013-11
Alvaro Herrera writes: > With apologies to our beloved commitfest-mace-wielding CFM, commitfest > 2013-11 intentionally still contains a few open patches. I think that > CF is largely being ignored by most people now that we have CF 2014-01 > in progress. If we don't want to do anything about these patches in the > immediate future, I propose we move them to CF 2014-01. I think the idea was that patch authors should take responsibility for pushing their patches forward to 2014-01 if they still wanted them considered. Quite a few patches already were moved that way, IIRC. Agreed though that we shouldn't let them just rot. > * shared memory message queues Isn't this committed? There's something by that name breaking the buildfarm ;-) > * Shave a few instructions from child-process startup sequence > Discussion stalled without a conclusion; opinions diverge on whether > this is a useful patch to have. My personal inclination is to drop > this patch because it seems pointless, but if someone feels otherwise > I won't object. I was one of the people objecting to it, so +1 for dropping. > * Widening application of indices. > Was this re-posted in 2014-01? Yes, there's a newer version already in 2014-01. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Closing commitfest 2013-11
With apologies to our beloved commitfest-mace-wielding CFM, commitfest 2013-11 intentionally still contains a few open patches. I think that CF is largely being ignored by most people now that we have CF 2014-01 in progress. If we don't want to do anything about these patches in the immediate future, I propose we move them to CF 2014-01. * shared memory message queues This is part of the suite involving dynamic shmem; not sure whether this is a patch that needs more review, or is it ready for application, or has it been superceded by later versions in the next commitfest. Patch authors please chime in. * Shave a few instructions from child-process startup sequence Discussion stalled without a conclusion; opinions diverge on whether this is a useful patch to have. My personal inclination is to drop this patch because it seems pointless, but if someone feels otherwise I won't object. (The objection that it will break as soon as we decide to change the invariant about invalid sockets no longer applies because it has Asserts to that effect.) Do we really care about performance during process termination? I'd say this is mildly interesting if this code is executed for non-authenticated clients. * Widening application of indices. Was this re-posted in 2014-01? * fault tolerant DROP IF EXISTS I gave a look and it looks good for application. This wasn't superceded by a future version, correct? * SSL: better default ciphersuite I think we should apply this. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers