Getting to beta1
in [PgSql]
|
From: Dimitri Fontaine on 15 Mar 2010 08:47 Greg Smith <greg(a)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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 15 Mar 2010 10:10 Dimitri Fontaine <dfontaine(a)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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Dimitri Fontaine on 15 Mar 2010 10:23 Tom Lane <tgl(a)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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Josh Berkus on 15 Mar 2010 14:02 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Bruce Momjian on 15 Mar 2010 16:24
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(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |