Re: [HACKERS] CommitFest Status Summary - 2010-02-14
Tom Lane wrote: I wrote: Robert Haas 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 -- 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] CommitFest Status Summary - 2010-02-14
I wrote: > Robert Haas 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 -- 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] CommitFest Status Summary - 2010-02-14
On Wed, Feb 17, 2010 at 6:39 AM, Tom Lane 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 -- 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] CommitFest Status Summary - 2010-02-14
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. -- 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] CommitFest Status Summary - 2010-02-14
On Wednesday 17 February 2010 07:39:16 Tom Lane wrote: > Robert Haas 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 -- 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] CommitFest Status Summary - 2010-02-14
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. -- 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] CommitFest Status Summary - 2010-02-14
Robert Haas 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 -- 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] CommitFest Status Summary - 2010-02-14
> 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 -- 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] CommitFest Status Summary - 2010-02-14
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 -- 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] CommitFest Status Summary - 2010-02-14
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. -- 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] CommitFest Status Summary - 2010-02-14
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 -- 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] CommitFest Status Summary - 2010-02-14
Tom Lane wrote: > Robert Haas 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 http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- 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] CommitFest Status Summary - 2010-02-14
(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 -- 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] CommitFest Status Summary - 2010-02-14
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.
commit d8c0d4e63c00606db95f95a9c8f2b7ccf3c819b3
Author: Tim Bunce
Date: Mon Feb 15 11:18:07 2010 +
Move on_proc_exit to after init (that may fail). Avoid Safe 2.21.
diff --git a/src/pl/plperl/plperl.c b/src/pl/plperl/plperl.c
index e950222..16d74a7 100644
--- a/src/pl/plperl/plperl.c
+++ b/src/pl/plperl/plperl.c
@@ -365,8 +365,6 @@ select_perl_context(bool trusted)
{
/* first actual use of a perl interpreter */
- on_proc_exit(plperl_fini, 0);
-
if (trusted)
{
plperl_trusted_init();
@@ -379,6 +377,10 @@ select_perl_context(bool trusted)
plperl_untrusted_interp = plperl_held_interp;
interp_state = INTERP_UNTRUSTED;
}
+
+ /* successfully initialized, so arrange for cleanup */
+ on_proc_exit(plperl_fini, 0);
+
}
else
{
@@ -685,8 +687,9 @@ plperl_trusted_init(void)
/*
* Reject too-old versions of Safe and some others:
* 2.20: http://rt.perl.org/rt3/Ticket/Display.html?id=72068
+ * 2.21: http://rt.perl.org/rt3/Ticket/Display.html?id=72700
*/
- if (safe_version_x100 < 209 || safe_version_x100 == 220)
+ if (safe_version_x100 < 209 || safe_version_x100 == 220 || safe_version_x100 == 221)
{
/* not safe, so disallow all trusted funcs */
eval_pv(PLC_SAFE_BAD, FALSE);
--
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] CommitFest Status Summary - 2010-02-14
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 probably be 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 -- 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] CommitFest Status Summary - 2010-02-14
> 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 -- 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] CommitFest Status Summary - 2010-02-14
Robert Haas 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
