Thread: Getting to beta1
Where are we in getting to beta1? I know people are looking to me for 9.0 release notes and I will have them done in about a week, but what about open issues? I don't see many on the main 9.0 open items page: http://wiki.postgresql.org/wiki/PostgreSQL_9.0_Open_Items#Bugs The list has been reduced greatly in the past week. What about HS/SR open items? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do
On Fri, 2010-03-12 at 22:28 -0500, Bruce Momjian wrote: > Where are we in getting to beta1? I know people are looking to me for > 9.0 release notes and I will have them done in about a week, but what > about open issues? I don't see many on the main 9.0 open items page: > > http://wiki.postgresql.org/wiki/PostgreSQL_9.0_Open_Items#Bugs > > The list has been reduced greatly in the past week. What about HS/SR > open items? I have these things on my list * Minor page xid bug fix * btree delete standby-side derivation of xid * review of StartupXLog issue, on open items list, has an effect on HS I expect to be finished with those by Wed, perhaps Thurs. Some additional open items on SR * trigger_file no longer supports "fast" mode. There is no way to startup server quickly if it has fallen behind, as is currently possible with 8.4 * There should be a default for "trigger_file" so that you can failover a server even if this has not been specified. To me the open items look like at least 2 weeks work on SR, given some of them will likely need discussion rather than just action. -- Simon Riggs www.2ndQuadrant.com
> The list has been reduced greatly in the past week. What about HS/SR > open items? I'd like to see vacuum_defer_cleanup_age added to the "Archive" section of postgresql.conf, and add it to the docs (I'll write something this week). I'd like to get rid of the associated hint-bits bogus error messsage. --Josh Berkus
Simon Riggs wrote: > I have these things on my list > > * Minor page xid bug fix > * btree delete standby-side derivation of xid > * review of StartupXLog issue, on open items list, has an effect on HS > > I expect to be finished with those by Wed, perhaps Thurs. Don't forget the "start from shutdown checkpoint" issue. > * There should be a default for "trigger_file" so that you can failover > a server even if this has not been specified. I disagree. In many cases, you never want to failover the standby, and having a default would just get in your way. > To me the open items look like at least 2 weeks work on SR, given some > of them will likely need discussion rather than just action. Yeah, I've unfortunately had very little to no time at all on SR recently. I must reserve some full days for that again... -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
On Sun, 2010-03-14 at 16:53 +0200, Heikki Linnakangas wrote: > Simon Riggs wrote: > > I have these things on my list > > > > * Minor page xid bug fix > > * btree delete standby-side derivation of xid > > * review of StartupXLog issue, on open items list, has an effect on HS > > > > I expect to be finished with those by Wed, perhaps Thurs. > > Don't forget the "start from shutdown checkpoint" issue. How could I? :-) > > * There should be a default for "trigger_file" so that you can failover > > a server even if this has not been specified. > > I disagree. In many cases, you never want to failover the standby, and > having a default would just get in your way. An explanation in the docs would be good. And also a hint of how to failover if you decide in an emergency that the absence was a mistake, in retrospect. > > To me the open items look like at least 2 weeks work on SR, given some > > of them will likely need discussion rather than just action. > > Yeah, I've unfortunately had very little to no time at all on SR > recently. I must reserve some full days for that again... 12 open items says "yes please" to that. -- Simon Riggs www.2ndQuadrant.com
On 3/14/10 9:02 AM, Simon Riggs wrote: > An explanation in the docs would be good. And also a hint of how to > failover if you decide in an emergency that the absence was a mistake, > in retrospect. I'm planning on writing a "Guide to HS & SR" for the beta. Originally I planned to put this in the main docs, but I couldn't figure out how to fit it in there structurally. Plus, it needs more examples, output samples, and a tutorial feel. --Josh Berkus
Devs, Also, I would like to have a Beta or at least a new alpha release before April 3 for the test-fest, so that our volunteers aren't testing bugs which are already patched. --Josh
On Mar 14, 2010, at 3:38 PM, Josh Berkus wrote: > I'm planning on writing a "Guide to HS & SR" for the beta. Originally I > planned to put this in the main docs, but I couldn't figure out how to > fit it in there structurally. Plus, it needs more examples, output > samples, and a tutorial feel. Perhaps a tutorial could go under Server Administration? Or perhaps under Tutorial even? It would be section I.4. http://developer.postgresql.org/pgdocs/postgres/index.html Frankly, I think more examples and tutorials in the docs would help newbies a *lot*. Best, David
On Sat, Mar 13, 2010 at 12:28 PM, Bruce Momjian <bruce@momjian.us> wrote: > Where are we in getting to beta1? I know people are looking to me for > 9.0 release notes and I will have them done in about a week, but what > about open issues? I don't see many on the main 9.0 open items page: > > http://wiki.postgresql.org/wiki/PostgreSQL_9.0_Open_Items#Bugs > > The list has been reduced greatly in the past week. What about HS/SR > open items? I think that at least the following item should be addressed before beta1 since it's a serious problem. * Walreceiver is not interruptible on win32 http://archives.postgresql.org/pgsql-hackers/2010-01/msg01672.php I've already submitted the patch, and am waiting for the review. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
"David E. Wheeler" <david@kineticode.com> writes:
> On Mar 14, 2010, at 3:38 PM, Josh Berkus wrote:
>
>> I'm planning on writing a "Guide to HS & SR" for the beta. Originally I
>> planned to put this in the main docs, but I couldn't figure out how to
>> fit it in there structurally. Plus, it needs more examples, output
>> samples, and a tutorial feel.
>
> Perhaps a tutorial could go under Server Administration? Or perhaps
> under Tutorial even? It would be section I.4.
+1 for having a Tutorial chapter about setting up archiving, PITR and
replication. While at it, let's read the release notes and list other
points that the tutorial could cover too.
Do we need some more sections in Chapter 3. Advanced Features, dealing
with Exclusion Constraint, the new DO command, how to manage privileges
in a realistic examples (a superuser role shared between 2 DBAs, the
database owner, and the application which is not allowed DDL, for
example)?
A psql chapter/section would maybe fit too, with tricks such as \o then
query the catalog then \i, ON_ERROR_{STOP,ROLLBACK}, -1, -v, PGOPTIONS,
etc, like Peter did in his last blog entry.
Maybe some more admin level tutorial would be great to have too, such as
how to find what's locking, how to monitor table and index usage to
determine which indexes to drop, which to create, how to monitor
<things> (slaves lag, hitratio, transactions, I/U/D activity, you name
it).
A lot of things are described in the manual and provided in munin or
nagios plugins already, but still the Tutorial looks like a good place
to give the recipes, ready-to-go queries etc.
Regards,
--
dim
Dimitri Fontaine wrote: > Maybe some more admin level tutorial would be great to have too, such as > how to find what's locking, how to monitor table and index usage to > determine which indexes to drop, which to create, how to monitor > <things> (slaves lag, hitratio, transactions, I/U/D activity, you name > it). > Wow, that's at least one order of magnitude more ambitious than the actual scope of work on the docs that should be getting focused on for beta right now, perhaps two. Regardless, I already have stubs for the first couple of these sitting on the wiki at http://wiki.postgresql.org/wiki/Category:Administration (locks, monitoring). I know I'd rather see work done on those, where we can continue to improve without doc commits and easily make things available for all versions, until that content is good. Maybe then we can talk about merging some of that back into the main docs. -- Greg Smith 2ndQuadrant US Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.us
Greg Smith <greg@2ndquadrant.com> writes: > Dimitri Fontaine wrote: >> Maybe some more admin level tutorial would be great to have too, such as >> how to find what's locking, how to monitor table and index usage to >> determine which indexes to drop, which to create, how to monitor >> <things> (slaves lag, hitratio, transactions, I/U/D activity, you name >> it). >> > > Wow, that's at least one order of magnitude more ambitious than the actual > scope of work on the docs that should be getting focused on for beta right > now, perhaps two. Yes, I took the message as an opportunity to talk about how much stuff we'd like to add in the tutorial, then I'll see about spending time on it if core agrees with the need. There's no reason I'd want this to happen pre-beta unless it's about hard to grasp things we want lots of people to test. So we're in agreement here... Maybe it's time to start another thread if people want to follow-up on expanding our tutorial. > Regardless, I already have stubs for the first couple of > these sitting on the wiki at > http://wiki.postgresql.org/wiki/Category:Administration (locks, monitoring). > I know I'd rather see work done on those, where we can continue to improve > without doc commits and easily make things available for all versions, until > that content is good. Maybe then we can talk about merging some of that > back into the main docs. Some kind of canonical reference on how to use the catalogs and system view to realise common tasks does not seem out of place in the tutorial for me. As far as using the wiki to prepare the content, +1. -- Dimitri Fontaine PostgreSQL DBA, Architecte
Dimitri Fontaine <dfontaine@hi-media.com> writes:
> A lot of things are described in the manual and provided in munin or
> nagios plugins already, but still the Tutorial looks like a good place
> to give the recipes, ready-to-go queries etc.
This sounds like a pretty horrid idea. The tutorial is meant to be read
first, so it cannot depend on having already read any of the main
documentation. If we try to fill it with "hints and tricks" then either
it will be completely unintelligible to newbies, or there will be a
staggering amount of material duplicated from the main docs to support
the hints. The latter approach would be no fun to write and even less
fun to maintain in the future.
There might well be a use for a separate hints-and-tricks document.
I don't agree with stuffing it into the existing tutorial though.
regards, tom lane
Tom Lane <tgl@sss.pgh.pa.us> writes: > This sounds like a pretty horrid idea. The tutorial is meant to be read > first, so it cannot depend on having already read any of the main > documentation. If we try to fill it with "hints and tricks" then either > it will be completely unintelligible to newbies, or there will be a > staggering amount of material duplicated from the main docs to support > the hints. The latter approach would be no fun to write and even less > fun to maintain in the future. I'm not sure how much your comment applies to what I picture, so here's what I had in mind: There's a system view called pg_stat_activity which is maintained up-to-date by PostgreSQL, and you can query it to gatherinformation about running queries at any time. Another such view is pg_locks, which reports about current lock requestsand whether they're granted or not. You can use both those system views to get important information on your running system, and to show currently waiting fora lock query texts, here's how you join those views: <insert recipe from the link> http://wiki.postgresql.org/wiki/Lock_Monitoring To produce a locking situation, let's open two concurrent connections to the database, either with psql in two differentterminals, or using pgadmin. Now <instruction for 2 concurrent UPDATE on the same row>. Use the previous query tosee the locked query, commit the first session to unlock it. As the concepts of SELECT, view and JOINs are already addressed in the tutorial, I'd think it could be ok. Now, maybe the tutorial isn't the right place to be confronted to MVCC, locks, and system monitoring, but some kind of soft introduction would be good here, methinks. > There might well be a use for a separate hints-and-tricks document. > I don't agree with stuffing it into the existing tutorial though. Yeah, maybe expanding current chapter 27. Monitoring Database Activity would be a better idea? http://developer.postgresql.org/pgdocs/postgres/monitoring.html In fact, a merge of chapters 27 and 28 Monitoring Disk Usage into a larger one about Monitoring PostgreSQL could be a better fit? Regards, -- dim
On 3/15/10 5:47 AM, Dimitri Fontaine wrote: > Maybe it's time to start another thread if people want to follow-up on > expanding our tutorial. Yes, and on pgsql-docs rather than on this mailing list. Or ... J.F.D.I (Just F---- Do It). That is, if someone contributed a whole buncha new text to the tutorial on pgsql-docs, I can't imagine it being rejected out of hand. For my part, I plan to just write the tutorial in whatever tool makes it easiest to write (likely Lyx, but maybe OOo). Then people can discuss what portions belong in the docs, or not. --Josh Berkus
Josh Berkus wrote: > Devs, > > Also, I would like to have a Beta or at least a new alpha release before > April 3 for the test-fest, so that our volunteers aren't testing bugs > which are already patched. We can easily create another alpha by April 3. I think the big question is whether we can put out beta1 while we still have open HS/SR issues. My guess is no. My other guess is that we will still have open HS/SR issues on April 3. So, putting those two guesses together, we will create a new alpha by April 3 for you. :-| -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do
On Mon, Mar 15, 2010 at 4:24 PM, Bruce Momjian <bruce@momjian.us> wrote: > We can easily create another alpha by April 3. I think the big question > is whether we can put out beta1 while we still have open HS/SR issues. > My guess is no. My other guess is that we will still have open HS/SR > issues on April 3. So, putting those two guesses together, we will > create a new alpha by April 3 for you. :-| I think we need to do a better job defining exactly what we think the "must fix" HS/SR issues are. Otherwise I can see this process of trying to get to beta dragging out almost indefinitely. ...Robert
Josh Berkus <josh@agliodbs.com> writes: > Yes, and on pgsql-docs rather than on this mailing list. > > Or ... J.F.D.I (Just F---- Do It). That is, if someone contributed a > whole buncha new text to the tutorial on pgsql-docs, I can't imagine it > being rejected out of hand. That was the bulk of the question, thanks for such a clear answer. I'll see about giving some time to that, out of the critical path to beta. > For my part, I plan to just write the tutorial in whatever tool makes it > easiest to write (likely Lyx, but maybe OOo). Then people can discuss > what portions belong in the docs, or not. Should I follow you on that choice or just send a doc patch with poor SGML markup? -- dim
All,
A user at SFPUG last night pointed out why we should release a beta,
rather than an alpha, sooner rather than later: because there are no
Windows packages for Alphas.
Currently, our Windows users are *not* testing 9.0. Which means we're
just putting off the day when we hear about Windows-specific bugs.
-- -- Josh Berkus PostgreSQL Experts Inc.
http://www.pgexperts.com
On Wed, Mar 17, 2010 at 4:54 PM, Josh Berkus <josh@agliodbs.com> wrote: > All, > > > A user at SFPUG last night pointed out why we should release a beta, > rather than an alpha, sooner rather than later: because there are no > Windows packages for Alphas. Yes there: http://www.enterprisedb.com/products/pgdevdownload.do We've produced them since Alpha 2 iirc. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com PG East Conference: http://www.enterprisedb.com/community/nav-pg-east-2010.do
> Yes there: http://www.enterprisedb.com/products/pgdevdownload.do > > We've produced them since Alpha 2 iirc. Oh! Most people don't know about these ... I need to advertise them! BTW, at SFPUG there were reports of some kind of issue with the One-Click installer for 8.4.3. Is that resolved, or is this the first time you've heard about it? -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.com
On Wed, Mar 17, 2010 at 5:02 PM, Josh Berkus <josh@agliodbs.com> wrote: > >> Yes there: http://www.enterprisedb.com/products/pgdevdownload.do >> >> We've produced them since Alpha 2 iirc. > > Oh! Most people don't know about these ... I need to advertise them! They're linked from here, which you may want to update as it was written in the pre-alpha days: http://www.postgresql.org/download/snapshots > BTW, at SFPUG there were reports of some kind of issue with the > One-Click installer for 8.4.3. Is that resolved, or is this the first > time you've heard about it? Not aware of any issues - certainly none cropped up in QA. In fact, this release should fix one of the long standing initdb failures we see occasionally on some secure environments. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com PG East Conference: http://www.enterprisedb.com/community/nav-pg-east-2010.do
> Not aware of any issues - certainly none cropped up in QA. In fact,
> this release should fix one of the long standing initdb failures we
> see occasionally on some secure environments.
OK, I'll ask on our mailing list.
-- -- Josh Berkus PostgreSQL Experts Inc.
http://www.pgexperts.com
On Sat, 2010-03-13 at 11:26 -0800, Josh Berkus wrote: > > The list has been reduced greatly in the past week. What about HS/SR > > open items? > > I'd like to see vacuum_defer_cleanup_age added to the "Archive" section > of postgresql.conf, Not all parameters are in postgresql.conf.sample. Encouraging people to do this is the wrong approach. > and add it to the docs (I'll write something this > week). It's already in the docs, so if they read it and understand it they can add it to the postgresql.conf if they so choose. > I'd like to get rid of the associated hint-bits bogus error > messsage. What are you talking about here? -- Simon Riggs www.2ndQuadrant.com
On Mon, 2010-03-15 at 18:20 +0900, Fujii Masao wrote: > On Sat, Mar 13, 2010 at 12:28 PM, Bruce Momjian <bruce@momjian.us> wrote: > > Where are we in getting to beta1? I know people are looking to me for > > 9.0 release notes and I will have them done in about a week, but what > > about open issues? I don't see many on the main 9.0 open items page: > > > > http://wiki.postgresql.org/wiki/PostgreSQL_9.0_Open_Items#Bugs > > > > The list has been reduced greatly in the past week. What about HS/SR > > open items? > > I think that at least the following item should be addressed before beta1 I think all the open items should be addressed before beta. -- Simon Riggs www.2ndQuadrant.com
Simon Riggs wrote: > On Sat, 2010-03-13 at 11:26 -0800, Josh Berkus wrote: > > > The list has been reduced greatly in the past week. What about HS/SR > > > open items? > > > > I'd like to see vacuum_defer_cleanup_age added to the "Archive" section > > of postgresql.conf, > > Not all parameters are in postgresql.conf.sample. Encouraging people to > do this is the wrong approach. > > > and add it to the docs (I'll write something this > > week). > > It's already in the docs, so if they read it and understand it they can > add it to the postgresql.conf if they so choose. I agree with Josh Berkus that vacuum_defer_cleanup_age should be in postgresql.conf. We don't stop listing items just because they are dangerous, e.g. fsync, or to discourage their use. I believe Greg Smith also felt it should be included. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do
Bruce Momjian wrote: > Simon Riggs wrote: > > On Sat, 2010-03-13 at 11:26 -0800, Josh Berkus wrote: > > > > The list has been reduced greatly in the past week. What about HS/SR > > > > open items? > > > > > > I'd like to see vacuum_defer_cleanup_age added to the "Archive" section > > > of postgresql.conf, > > > > Not all parameters are in postgresql.conf.sample. Encouraging people to > > do this is the wrong approach. > > > > > and add it to the docs (I'll write something this > > > week). > > > > It's already in the docs, so if they read it and understand it they can > > add it to the postgresql.conf if they so choose. > > I agree with Josh Berkus that vacuum_defer_cleanup_age should be in > postgresql.conf. We don't stop listing items just because they are > dangerous, e.g. fsync, or to discourage their use. I believe Greg Smith > also felt it should be included. The bottom line is that the fact that vacuum_defer_cleanup_age is missing from postgresql.conf is causing confusion because none of the other settings are skipped to discourage their use. If you want to apply that policy, we would have to revisit all the postgresql.conf settings, and I don't think there is much interest in doing that. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do
On Wed, Mar 17, 2010 at 11:42 PM, Bruce Momjian <bruce@momjian.us> wrote: > Bruce Momjian wrote: >> Simon Riggs wrote: >> > On Sat, 2010-03-13 at 11:26 -0800, Josh Berkus wrote: >> > > > The list has been reduced greatly in the past week. What about HS/SR >> > > > open items? >> > > >> > > I'd like to see vacuum_defer_cleanup_age added to the "Archive" section >> > > of postgresql.conf, >> > >> > Not all parameters are in postgresql.conf.sample. Encouraging people to >> > do this is the wrong approach. >> > >> > > and add it to the docs (I'll write something this >> > > week). >> > >> > It's already in the docs, so if they read it and understand it they can >> > add it to the postgresql.conf if they so choose. >> >> I agree with Josh Berkus that vacuum_defer_cleanup_age should be in >> postgresql.conf. We don't stop listing items just because they are >> dangerous, e.g. fsync, or to discourage their use. I believe Greg Smith >> also felt it should be included. > > The bottom line is that the fact that vacuum_defer_cleanup_age is > missing from postgresql.conf is causing confusion because none of the > other settings are skipped to discourage their use. If you want to > apply that policy, we would have to revisit all the postgresql.conf > settings, and I don't think there is much interest in doing that. I agree. If we're going to have the option, it should be in the file. ...Robert
On Wed, 2010-03-17 at 23:29 -0400, Bruce Momjian wrote: > Simon Riggs wrote: > > On Sat, 2010-03-13 at 11:26 -0800, Josh Berkus wrote: > > > > The list has been reduced greatly in the past week. What about HS/SR > > > > open items? > > > > > > I'd like to see vacuum_defer_cleanup_age added to the "Archive" section > > > of postgresql.conf, > > > > Not all parameters are in postgresql.conf.sample. Encouraging people to > > do this is the wrong approach. > > > I agree with Josh Berkus that vacuum_defer_cleanup_age should be in > postgresql.conf. We don't stop listing items just because they are > dangerous, e.g. fsync, or to discourage their use. I believe Greg Smith > also felt it should be included. Added to postgresql.conf.sample -- Simon Riggs www.2ndQuadrant.com
>> It's already in the docs, so if they read it and understand it they can
>> add it to the postgresql.conf if they so choose.
>
> I agree with Josh Berkus that vacuum_defer_cleanup_age should be in
> postgresql.conf. We don't stop listing items just because they are
> dangerous, e.g. fsync, or to discourage their use. I believe Greg Smith
> also felt it should be included.
Or, let's put it another way: I've made my opinion clear in the past
that I think that we ought to ship with a minimal postgresql.conf with
maybe 15 items in it. If we are going to continue to ship with
postgresql.conf "kitchen sick" version, however, it should include
vacuum_defer_cleanup_age.
-- -- Josh Berkus PostgreSQL Experts Inc.
http://www.pgexperts.com
On Thu, 2010-03-18 at 10:18 -0700, Josh Berkus wrote: > >> It's already in the docs, so if they read it and understand it they can > >> add it to the postgresql.conf if they so choose. > > > > I agree with Josh Berkus that vacuum_defer_cleanup_age should be in > > postgresql.conf. We don't stop listing items just because they are > > dangerous, e.g. fsync, or to discourage their use. I believe Greg Smith > > also felt it should be included. > > Or, let's put it another way: I've made my opinion clear in the past > that I think that we ought to ship with a minimal postgresql.conf with > maybe 15 items in it. If we are going to continue to ship with > postgresql.conf "kitchen sick" version, however, it should include > vacuum_defer_cleanup_age. +1 As usual, the postgresql.conf is entirely too full. We should ship with the top 15. If this gains any traction, I am sure that Greg Smith, Berkus and I could provide that list with nothing but a care bear discussion. Joshua D. Drake > > -- > -- Josh Berkus > PostgreSQL Experts Inc. > http://www.pgexperts.com > -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering Respect is earned, not gained through arbitrary and repetitive use or Mr. or Sir.
Joshua D. Drake wrote: > As usual, the postgresql.conf is entirely too full. We should ship with > the top 15. Maybe, but what we should do is ship, and then talk about this again when it's appropriate--earlier in the release cycle. Let me try and cut this one off before it generates a bunch of traffic by summarizing where this is stuck at. We started this release with a good plan for pulling off a major postgresql.conf trimming effort that I still like a lot ( http://wiki.postgresql.org/wiki/PgCon_2009_Developer_Meeting#Auto-Tuning ) The first step was switching over to a directory-based structure that allowed being all things to all people just by selecting which of the files provided you put into there. We really need the things initdb touches to go into a separate file, rather than the bloated sample, in a way that it's easy to manage; if you just drop files into a directory and the server reads them all that's the easiest route. Extending to include the top 15 or whatever other subset people want is easy after that. Now, that didn't go anywhere in this release due to development focus constraints, but I'm willing to take "has what we can advertise as built-in replication" as a disappointing but acceptable substitute in lieu of that. (rolls eyes) I think it will fit nicely into the "9.1 adds the polish" theme already gathering around the replication features being postponed to the next release. -- Greg Smith 2ndQuadrant US Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.us
On Thu, 18 Mar 2010, Joshua D. Drake wrote: > On Thu, 2010-03-18 at 10:18 -0700, Josh Berkus wrote: >>>> It's already in the docs, so if they read it and understand it they can >>>> add it to the postgresql.conf if they so choose. >>> >>> I agree with Josh Berkus that vacuum_defer_cleanup_age should be in >>> postgresql.conf. We don't stop listing items just because they are >>> dangerous, e.g. fsync, or to discourage their use. I believe Greg Smith >>> also felt it should be included. >> >> Or, let's put it another way: I've made my opinion clear in the past >> that I think that we ought to ship with a minimal postgresql.conf with >> maybe 15 items in it. If we are going to continue to ship with >> postgresql.conf "kitchen sick" version, however, it should include >> vacuum_defer_cleanup_age. > > +1 > > As usual, the postgresql.conf is entirely too full. We should ship with > the top 15. If this gains any traction, I am sure that Greg Smith, > Berkus and I could provide that list with nothing but a care bear > discussion. +1 ... but, why the 'top 15'? why not just those that are uncommented to start with, and leave those that are commented out as 'in the docs' ... ? ---- Marc G. Fournier Hub.Org Hosting Solutions S.A. scrappy@hub.org http://www.hub.org Yahoo:yscrappy Skype: hub.org ICQ:7615664 MSN:scrappy@hub.org
On Thu, Mar 18, 2010 at 4:28 PM, Marc G. Fournier <scrappy@hub.org> wrote: > On Thu, 18 Mar 2010, Joshua D. Drake wrote: > >> On Thu, 2010-03-18 at 10:18 -0700, Josh Berkus wrote: >>>>> >>>>> It's already in the docs, so if they read it and understand it they can >>>>> add it to the postgresql.conf if they so choose. >>>> >>>> I agree with Josh Berkus that vacuum_defer_cleanup_age should be in >>>> postgresql.conf. We don't stop listing items just because they are >>>> dangerous, e.g. fsync, or to discourage their use. I believe Greg Smith >>>> also felt it should be included. >>> >>> Or, let's put it another way: I've made my opinion clear in the past >>> that I think that we ought to ship with a minimal postgresql.conf with >>> maybe 15 items in it. If we are going to continue to ship with >>> postgresql.conf "kitchen sick" version, however, it should include >>> vacuum_defer_cleanup_age. >> >> +1 >> >> As usual, the postgresql.conf is entirely too full. We should ship with >> the top 15. If this gains any traction, I am sure that Greg Smith, >> Berkus and I could provide that list with nothing but a care bear >> discussion. > > +1 ... but, why the 'top 15'? why not just those that are uncommented to > start with, and leave those that are commented out as 'in the docs' ... ? +1 to either proposal. ...Robert
On Thu, 2010-03-18 at 19:10 -0400, Robert Haas wrote: > On Thu, Mar 18, 2010 at 4:28 PM, Marc G. Fournier <scrappy@hub.org> wrote: > > On Thu, 18 Mar 2010, Joshua D. Drake wrote: > > > >> On Thu, 2010-03-18 at 10:18 -0700, Josh Berkus wrote: > >>>>> > >>>>> It's already in the docs, so if they read it and understand it they can > >>>>> add it to the postgresql.conf if they so choose. > >>>> > >>>> I agree with Josh Berkus that vacuum_defer_cleanup_age should be in > >>>> postgresql.conf. We don't stop listing items just because they are > >>>> dangerous, e.g. fsync, or to discourage their use. I believe Greg Smith > >>>> also felt it should be included. > >>> > >>> Or, let's put it another way: I've made my opinion clear in the past > >>> that I think that we ought to ship with a minimal postgresql.conf with > >>> maybe 15 items in it. If we are going to continue to ship with > >>> postgresql.conf "kitchen sick" version, however, it should include > >>> vacuum_defer_cleanup_age. > >> > >> +1 > >> > >> As usual, the postgresql.conf is entirely too full. We should ship with > >> the top 15. If this gains any traction, I am sure that Greg Smith, > >> Berkus and I could provide that list with nothing but a care bear > >> discussion. > > > > +1 ... but, why the 'top 15'? why not just those that are uncommented to > > start with, and leave those that are commented out as 'in the docs' ... ? > > +1 to either proposal. I think top 15 was arbitrary. The point, is that our postgresql.conf is ridiculous. For 99% of installations, only a dozen to a dozen and a half of the options are relevant. > > ...Robert > -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering Respect is earned, not gained through arbitrary and repetitive use or Mr. or Sir.
On Thu, 2010-03-18 at 10:18 -0700, Josh Berkus wrote: > >> It's already in the docs, so if they read it and understand it they can > >> add it to the postgresql.conf if they so choose. > > > > I agree with Josh Berkus that vacuum_defer_cleanup_age should be in > > postgresql.conf. We don't stop listing items just because they are > > dangerous, e.g. fsync, or to discourage their use. I believe Greg Smith > > also felt it should be included. > > Or, let's put it another way: I've made my opinion clear in the past > that I think that we ought to ship with a minimal postgresql.conf with > maybe 15 items in it. If we are going to continue to ship with > postgresql.conf "kitchen sick" version, however, it should include > vacuum_defer_cleanup_age. +1 As usual, the postgresql.conf is entirely too full. We should ship with the top 15. If this gains any traction, I am sure that Greg Smith, Berkus and I could provide that list with nothing but a care bear discussion. Joshua D. Drake > > -- > -- Josh Berkus > PostgreSQL Experts Inc. > http://www.pgexperts.com > -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering Respect is earned, not gained through arbitrary and repetitive use or Mr. or Sir.
Robert Haas wrote: > On Thu, Mar 18, 2010 at 4:28 PM, Marc G. Fournier <scrappy@hub.org> wrote: > >> On Thu, 18 Mar 2010, Joshua D. Drake wrote: >> >> >>> On Thu, 2010-03-18 at 10:18 -0700, Josh Berkus wrote: >>> >>>> >>>> Or, let's put it another way: I've made my opinion clear in the past >>>> that I think that we ought to ship with a minimal postgresql.conf with >>>> maybe 15 items in it. >>> +1 >>> >> +1 ... but, why the 'top 15'? why not just those that are uncommented to >> start with, and leave those that are commented out as 'in the docs' ... ? >> > +1 to either proposal. > If this is turning into a vote: -1 from me for any work on this until http://wiki.postgresql.org/wiki/PostgreSQL_9.0_Open_Items is cleared. It boggles my mind that anyone could have a different prioritization right now. -- Greg Smith 2ndQuadrant US Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.us
On 3/18/10 4:54 PM, Greg Smith wrote: > > If this is turning into a vote: -1 from me for any work on this until > http://wiki.postgresql.org/wiki/PostgreSQL_9.0_Open_Items is cleared. > It boggles my mind that anyone could have a different prioritization > right now. Yes. I wasn't suggesting that we change postgresql.conf.sample for this release. Feature Freeze was a while ago. -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.com
On Thu, Mar 18, 2010 at 7:54 PM, Greg Smith <greg@2ndquadrant.com> wrote: > If this is turning into a vote: -1 from me for any work on this until > http://wiki.postgresql.org/wiki/PostgreSQL_9.0_Open_Items is cleared. It > boggles my mind that anyone could have a different prioritization right now. This isn't about priority, at least in my mind. It's about consensus.If we have consensus, the work can get done for 9.1. It seems like everyone is on the same page - that is a good thing. ...Robert
On Thu, 2010-03-18 at 19:10 -0400, Robert Haas wrote: > On Thu, Mar 18, 2010 at 4:28 PM, Marc G. Fournier <scrappy@hub.org> wrote: > > On Thu, 18 Mar 2010, Joshua D. Drake wrote: > > > >> On Thu, 2010-03-18 at 10:18 -0700, Josh Berkus wrote: > >>>>> > >>>>> It's already in the docs, so if they read it and understand it they can > >>>>> add it to the postgresql.conf if they so choose. > >>>> > >>>> I agree with Josh Berkus that vacuum_defer_cleanup_age should be in > >>>> postgresql.conf. We don't stop listing items just because they are > >>>> dangerous, e.g. fsync, or to discourage their use. I believe Greg Smith > >>>> also felt it should be included. > >>> > >>> Or, let's put it another way: I've made my opinion clear in the past > >>> that I think that we ought to ship with a minimal postgresql.conf with > >>> maybe 15 items in it. If we are going to continue to ship with > >>> postgresql.conf "kitchen sick" version, however, it should include > >>> vacuum_defer_cleanup_age. > >> > >> +1 > >> > >> As usual, the postgresql.conf is entirely too full. We should ship with > >> the top 15. If this gains any traction, I am sure that Greg Smith, > >> Berkus and I could provide that list with nothing but a care bear > >> discussion. > > > > +1 ... but, why the 'top 15'? why not just those that are uncommented to > > start with, and leave those that are commented out as 'in the docs' ... ? > > +1 to either proposal. I think top 15 was arbitrary. The point, is that our postgresql.conf is ridiculous. For 99% of installations, only a dozen to a dozen and a half of the options are relevant. > > ...Robert > -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering Respect is earned, not gained through arbitrary and repetitive use or Mr. or Sir.
On Sat, 2010-03-13 at 16:58 +0000, Simon Riggs wrote: > On Fri, 2010-03-12 at 22:28 -0500, Bruce Momjian wrote: > > > Where are we in getting to beta1? I know people are looking to me for > > 9.0 release notes and I will have them done in about a week, but what > > about open issues? I don't see many on the main 9.0 open items page: > > > > http://wiki.postgresql.org/wiki/PostgreSQL_9.0_Open_Items#Bugs > > > > The list has been reduced greatly in the past week. What about HS/SR > > open items? > > I have these things on my list > > * Minor page xid bug fix COMMITTED > * btree delete standby-side derivation of xid MOST HACKING DONE, TESTING NOW > * review of StartupXLog issue, on open items list, has an effect on HS DONE - no action > I expect to be finished with those by Wed, perhaps Thurs. * Start from Shutdown checkpoint Adding the last one will take me through to next week now, but given the list of outstanding SR issues, I figure I have that time. -- Simon Riggs www.2ndQuadrant.com
Hi all, On Thu, 2010-03-18 at 10:18 -0700, Josh Berkus wrote: > Or, let's put it another way: I've made my opinion clear in the past > that I think that we ought to ship with a minimal postgresql.conf with > maybe 15 items in it. If we are going to continue to ship with > postgresql.conf "kitchen sick" version, however, it should include > vacuum_defer_cleanup_age. But considering that these are samples anyway, what is preventing to ship 2 versions, one labeled "minimal" and one labeled "full" ? The minimal one should only contain absolutely must-change items, and the full version should contain all. As simple as that. I don't think there's any value in anything in the middle... Cheers, Csaba.