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 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
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.
Attachments:
on_proc_exit-safe-221.patchtext/x-patch; charset=us-asciiDownload
commit d8c0d4e63c00606db95f95a9c8f2b7ccf3c819b3
Author: Tim Bunce <Tim.Bunce@pobox.com>
Date: Mon Feb 15 11:18:07 2010 +0000
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);
(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.
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
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
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