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 HSI 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 HSI 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 gather information
about running queries at any time. Another such view is pg_locks,
which reports about current lock requests and 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 for a 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 different terminals, or using
pgadmin. Now <instruction for 2 concurrent UPDATE on the same
row>. Use the previous query to see 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.
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
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.
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