Thread: CommitFest Status Summary - 2010-02-14
We're down to 5 patches remaining, and 1 day remaining, so it's time to try to wrap things up. * Fix large object support in pg_dump. I think this is just waiting for a second opinion on whether the approach is correct. I've been meaning to look at it, but haven't gotten enough round tuits; maybe someone else would like to take a look? This is an open item, so we should really try to deal with it. * Faster CREATE DATABASE by delaying fsync. This is really two patches now, one of which is apparently to be backpatched. Greg Stark was going to commit it, but perhaps if he isn't around someone else should pick it up. * Provide rowcount for utility SELECTs. Bruce just posted an updated version of this patch. I think it's pretty much ready to go. * Package namespace and Safe init cleanup for plperl. Andrew Dunstan is taking care of this one, I believe. * Listen / Notify rewrite. This is the only one of the remaining patches that is not marked as Ready for Committer, but I think it would be good if someone (probably Tom) at least took a look at it. I'm not sure if it's committable at this point, but we should at least try to provide some good feedback. ...Robert
Robert Haas <robertmhaas@gmail.com> writes:
> * Listen / Notify rewrite. This is the only one of the remaining
> patches that is not marked as Ready for Committer, but I think it
> would be good if someone (probably Tom) at least took a look at it.
> I'm not sure if it's committable at this point, but we should at least
> try to provide some good feedback.
I will look at this one. It'd be nice to get it in if at all possible,
because the existing listen/notify infrastructure won't play very nicely
with HS --- eg, inspecting pg_listener on the slave might yield the
false impression that some of the slave-side backends had active LISTENs
because of chance matches of PID.
regards, tom lane
> I will look at this one. It'd be nice to get it in if at all possible, > because the existing listen/notify infrastructure won't play very nicely > with HS --- eg, inspecting pg_listener on the slave might yield the > false impression that some of the slave-side backends had active LISTENs > because of chance matches of PID. It'll also serve a major need for integrating PostgreSQL with caching infrastructures. So it's not just an "insider" feature. --Josh Berkus
Robert Haas wrote: > We're down to 5 patches remaining, and 1 day remaining, so it's time > to try to wrap things up. > > > * Package namespace and Safe init cleanup for plperl. Andrew Dunstan > is taking care of this one, I believe. > > I will get this in, with changes as discussed recently. I also have two small action items I want to get into the alpha: * change perl warnings to emit messages at WARNING rather than NOTICE level as recently discussed. This can probablybe done as part of the above patch. * add the query text to auto-explain output, as I proposed some time ago, and was generally approved. I think it's desirable for us to have this from the get-go for XML explain output.This isn't in the commitfest, but the patch is very small, and it's really a cleanup item, I think. I will be returning home in the next 24 hours and will try to get all this in within 24 hours of that. But I can't make it by tomorrow. I'm too tired now and I want to avoid mistakes. cheers andrew
On Sun, Feb 14, 2010 at 10:14:28PM -0500, Andrew Dunstan wrote:
>
> Robert Haas wrote:
> >We're down to 5 patches remaining, and 1 day remaining, so it's time
> >to try to wrap things up.
> >
> >* Package namespace and Safe init cleanup for plperl. Andrew Dunstan
> >is taking care of this one, I believe.
>
> I will get this in, with changes as discussed recently.
Here's a small extra patch for your consideration.
It addresses a couple of minor loose-ends in plperl:
- move on_proc_exit() call to after the plperl_*_init() calls
so on_proc_exit will only be called if plperl_*_init() succeeds
(else there's a risk of on_proc_exit consuming all the exit hook slots)
- don't allow use of Safe version 2.21 as that's broken for PL/Perl.
Tim.
Attachment
(2010/02/14 13:34), Robert Haas wrote: > * Fix large object support in pg_dump. I think this is just waiting > for a second opinion on whether the approach is correct. I've been > meaning to look at it, but haven't gotten enough round tuits; maybe > someone else would like to take a look? This is an open item, so we > should really try to deal with it. Do I have anything I can work on this right now? Because I'll be unavailable at the next week, I'd like to fix up it within this week, if possible. -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com>
Tom Lane wrote: > Robert Haas <robertmhaas@gmail.com> writes: > > * Listen / Notify rewrite. This is the only one of the remaining > > patches that is not marked as Ready for Committer, but I think it > > would be good if someone (probably Tom) at least took a look at it. > > I'm not sure if it's committable at this point, but we should at least > > try to provide some good feedback. > > I will look at this one. It'd be nice to get it in if at all possible, > because the existing listen/notify infrastructure won't play very nicely > with HS --- eg, inspecting pg_listener on the slave might yield the > false impression that some of the slave-side backends had active LISTENs > because of chance matches of PID. Good point. Is pg_listener the only place we expose PIDs in heap files? I know we expose them in views but those are not affected by HS, I believe. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Tim Bunce wrote: > On Sun, Feb 14, 2010 at 10:14:28PM -0500, Andrew Dunstan wrote: > >> Robert Haas wrote: >> >>> We're down to 5 patches remaining, and 1 day remaining, so it's time >>> to try to wrap things up. >>> >>> * Package namespace and Safe init cleanup for plperl. Andrew Dunstan >>> is taking care of this one, I believe. >>> >> I will get this in, with changes as discussed recently. >> > > Here's a small extra patch for your consideration. > > It addresses a couple of minor loose-ends in plperl: > - move on_proc_exit() call to after the plperl_*_init() calls > so on_proc_exit will only be called if plperl_*_init() succeeds > (else there's a risk of on_proc_exit consuming all the exit hook slots) > - don't allow use of Safe version 2.21 as that's broken for PL/Perl. > > > I have committed all the plperl changes that were under discussion, including this, and the change to the log level of perl warnings. Thanks for all your work, Tim, you have certainly given plperl a huge booster shot. cheers andrew
On Tue, Feb 16, 2010 at 04:42:29PM -0500, Andrew Dunstan wrote: > Tim Bunce wrote: > >On Sun, Feb 14, 2010 at 10:14:28PM -0500, Andrew Dunstan wrote: > >>Robert Haas wrote: > >>>We're down to 5 patches remaining, and 1 day remaining, so it's time > >>>to try to wrap things up. > >>> > >>>* Package namespace and Safe init cleanup for plperl. Andrew Dunstan > >>>is taking care of this one, I believe. > >> > >>I will get this in, with changes as discussed recently. > > > >Here's a small extra patch for your consideration. > > > >It addresses a couple of minor loose-ends in plperl: > >- move on_proc_exit() call to after the plperl_*_init() calls > > so on_proc_exit will only be called if plperl_*_init() succeeds > > (else there's a risk of on_proc_exit consuming all the exit hook slots) > >- don't allow use of Safe version 2.21 as that's broken for PL/Perl. > > I have committed all the plperl changes that were under discussion, > including this, and the change to the log level of perl warnings. > > Thanks for all your work, Tim, you have certainly given plperl a > huge booster shot. Thanks Andrew! And many thanks to you and the rest of the PostgreSQL developers for all your support/resistance/reviews along the way. The final changes are certainly better in many ways (though not all ;-) from my original patches. It's certainly been an interesting introduction to PostgreSQL development! Tim. p.s. One quick heads-up: David Wheeler has reported a possible issue with Safe 2.21. I hope to investigate that tomorrow.
On Feb 16, 2010, at 2:19 PM, Tim Bunce wrote: > It's certainly been an interesting introduction to PostgreSQL development! "Interesting," eh? Look forward to your blog post about the experience. ;-P > Tim. > > p.s. One quick heads-up: David Wheeler has reported a possible issue > with Safe 2.21. I hope to investigate that tomorrow. Actually it's 2.22. 2.21 is already dead. David
> It's certainly been an interesting introduction to PostgreSQL > development! Hopefully we haven't scared you off - your work is definitely very much appreciated (and I at least hope to see you back for 9.1)! ...Robert
> It's certainly been an interesting introduction to PostgreSQL > development! Hopefully we haven't scared you off - your work is definitely very much appreciated (and I at least hope to see you back for 9.1)! ...Robert
Robert Haas <robertmhaas@gmail.com> writes:
> * Fix large object support in pg_dump. I think this is just waiting
> for a second opinion on whether the approach is correct. I've been
> meaning to look at it, but haven't gotten enough round tuits; maybe
> someone else would like to take a look? This is an open item, so we
> should really try to deal with it.
Yeah, I think this is a "must fix for alpha" item. Will look at it
tomorrow, god willin an the creek don't rise (or, given the weather
around here: the power stays on).
> * Faster CREATE DATABASE by delaying fsync. This is really two
> patches now, one of which is apparently to be backpatched.
This one (both parts) seems to have crashed and burned on unexpected
portability issues :-(. Do we have any expectation of being able to
fix it before alpha4?
regards, tom lane
On Tue, Feb 16, 2010 at 02:25:00PM -0800, David E. Wheeler wrote: > On Feb 16, 2010, at 2:19 PM, Tim Bunce wrote: > > > p.s. One quick heads-up: David Wheeler has reported a possible issue > > with Safe 2.21. I hope to investigate that tomorrow. > > Actually it's 2.22. 2.21 is already dead. Oops, typo. At this stage I think the problem is that the call to utf8fix (that's made when the compartment is initialized) is failing due to the extra security in Safe 2.2x. If so, PostgreSQL 9.0 will be fine but 8.x and earlier will require a patch. I'll start a new thread when I have some concrete information. Tim.
On Wednesday 17 February 2010 07:39:16 Tom Lane wrote: > Robert Haas <robertmhaas@gmail.com> writes: > > * Fix large object support in pg_dump. I think this is just waiting > > for a second opinion on whether the approach is correct. I've been > > meaning to look at it, but haven't gotten enough round tuits; maybe > > someone else would like to take a look? This is an open item, so we > > should really try to deal with it. > > Yeah, I think this is a "must fix for alpha" item. Will look at it > tomorrow, god willin an the creek don't rise (or, given the weather > around here: the power stays on). > > > * Faster CREATE DATABASE by delaying fsync. This is really two > > patches now, one of which is apparently to be backpatched. > > This one (both parts) seems to have crashed and burned on unexpected > portability issues :-(. Do we have any expectation of being able to > fix it before alpha4? The "Faster" part has burned as well? I just looked at the buildfarm and didnt see anything. Care to point anything out? For the directory part I think we should aim for a more complete patch if I (or somebody else) can prove that its an issue (of what I am personally quite certain of). I think Greg just reverted the last patch (for 8.1). The latter for sure wont happen before weekend and I dont really see it bound for alpha4? Andres
On Tue, Feb 16, 2010 at 05:22:27PM -0500, Robert Haas wrote: > > It's certainly been an interesting introduction to PostgreSQL > > development! > > Hopefully we haven't scared you off - your work is definitely very > much appreciated (and I at least hope to see you back for 9.1)! Thanks Robert. That's nice to hear. I'd be happy to do more for 9.1 (subject to the ongoing generosity of my client http://TigerLead.com who are the ones to thank for my work on PostgreSQL). Tim.
On Wed, Feb 17, 2010 at 6:39 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> * Faster CREATE DATABASE by delaying fsync. This is really two >> patches now, one of which is apparently to be backpatched. > > This one (both parts) seems to have crashed and burned on unexpected > portability issues :-(. Do we have any expectation of being able to > fix it before alpha4? The current status is that the patch is in HEAD but the one line fsyncing the directory is #ifdef'd out. The backpatched fsync of the directory is entirely reverted from early branches. However I was just looking at the code and realized it has a file descriptor leak if an error occurs re-opening the files to fsync them. But then the same file descriptor leak is there if it has an error opening the destination file so I guess this isn't a new bug. -- greg
I wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> * Fix large object support in pg_dump. I think this is just waiting
>> for a second opinion on whether the approach is correct. I've been
>> meaning to look at it, but haven't gotten enough round tuits; maybe
>> someone else would like to take a look? This is an open item, so we
>> should really try to deal with it.
> Yeah, I think this is a "must fix for alpha" item. Will look at it
> tomorrow, god willin an the creek don't rise (or, given the weather
> around here: the power stays on).
I've applied that patch after some revisions.
The only thing still showing as open in the CommitFest webpage is
the last plperl patch. I think that's actually done but not marked
as committed; Andrew?
regards, tom lane
Tom Lane wrote: > I wrote: > >> Robert Haas <robertmhaas@gmail.com> writes: >> >>> * Fix large object support in pg_dump. I think this is just waiting >>> for a second opinion on whether the approach is correct. I've been >>> meaning to look at it, but haven't gotten enough round tuits; maybe >>> someone else would like to take a look? This is an open item, so we >>> should really try to deal with it. >>> > > >> Yeah, I think this is a "must fix for alpha" item. Will look at it >> tomorrow, god willin an the creek don't rise (or, given the weather >> around here: the power stays on). >> > > I've applied that patch after some revisions. > > The only thing still showing as open in the CommitFest webpage is > the last plperl patch. I think that's actually done but not marked > as committed; Andrew? > > > sorry. fixed. cheers andrew