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

Search Discussions

  • Tom Lane at Feb 14, 2010 at 5:53 pm

    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
  • Josh Berkus at Feb 14, 2010 at 6:33 pm

    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
  • Bruce Momjian at Feb 16, 2010 at 4:13 pm

    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. +
  • Andrew Dunstan at Feb 15, 2010 at 3:16 am

    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
  • Tim Bunce at Feb 15, 2010 at 11:33 am

    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.
  • Andrew Dunstan at Feb 16, 2010 at 9:42 pm

    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
  • Tim Bunce at Feb 16, 2010 at 10:19 pm

    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.
  • David E. Wheeler at Feb 16, 2010 at 10:25 pm

    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
  • Tim Bunce at Feb 17, 2010 at 12:03 pm

    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.
  • Robert Haas at Feb 16, 2010 at 10:30 pm

    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
  • Tim Bunce at Feb 17, 2010 at 12:14 pm

    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.
  • KaiGai Kohei at Feb 16, 2010 at 5:10 am

    (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 at Feb 17, 2010 at 6:39 am

    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
  • Andres Freund at Feb 17, 2010 at 12:08 pm

    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
  • Greg Stark at Feb 17, 2010 at 12:26 pm

    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
  • Tom Lane at Feb 18, 2010 at 1:32 am

    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
  • Andrew Dunstan at Feb 18, 2010 at 2:27 am

    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedFeb 14, '10 at 4:35a
activeFeb 18, '10 at 2:27a
posts18
users10
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2022 Grokbase