Streaming replication status
in [PgSql]
|
From: Stefan Kaltenbrunner on 12 Jan 2010 16:02 Simon Riggs wrote: > On Tue, 2010-01-12 at 15:11 -0500, Bruce Momjian wrote: >> Stefan Kaltenbrunner wrote: >>> Simon Riggs wrote: >>>> On Tue, 2010-01-12 at 08:24 +0100, Stefan Kaltenbrunner wrote: >>>>> Fujii Masao wrote: >>>>>> On Tue, Jan 12, 2010 at 1:21 PM, Greg Smith <greg(a)2ndquadrant.com> wrote: >>>>>>> I don't think anybody can deploy this feature without at least some very >>>>>>> basic monitoring here. I like the basic proposal you made back in September >>>>>>> for adding a pg_standbys_xlog_location to replace what you have to get from >>>>>>> ps right now: >>>>>>> http://archives.postgresql.org/pgsql-hackers/2009-09/msg00889.php >>>>>>> >>>>>>> That's basic, but enough that people could get by for a V1. >>>>>> Yeah, I have no objection to add such simple capability which monitors >>>>>> the lag into the first release. But I guess that, in addition to that, >>>>>> Simon wanted the capability to collect the statistical information about >>>>>> replication activity (e.g., a transfer time, a write time, replay time). >>>>>> So I'd like to postpone it. >>>>> yeah getting that would all be nice and handy but we have to remember >>>>> that this is really our first cut at integrated replication. Being able >>>>> to monitor lag is what is needed as a minimum, more advanced stuff can >>>>> and will emerge once we get some actual feedback from the field. >>>> Though there won't be any feedback from the field because there won't be >>>> any numbers to discuss. Just "it appears to be working". Then we will go >>>> into production and the problems will begin to be reported. We will be >>>> able to do nothing to resolve them because we won't know how many people >>>> are affected. >>> field is also production usage in my pov, and I'm not sure how we would >>> know how many people are affected by some imaginary issue just because >>> there is a column that has some numbers in it. >>> All of the large features we added in the past got finetuned and >>> improved in the following releases, and I expect SR to be one of them >>> that will see a lot of improvement in 8.5+n. >>> Adding detailed monitoring of some random stuff (I don't think there was >>> a clear proposal of what kind of stuff you would like to see) while we >>> don't really know what the performance characteristics are might easily >>> lead to us provding a ton of data and nothing relevant :( >>> What I really think we should do for this first cut is to make it as >>> foolproof and easy to set up as possible and add the minimum required >>> monitoring knobs but not going overboard with doing too many stats. >> I totally agree. If SR isn't going to be useful without being >> feature-complete, we might as well just drop it for 8.5 right now. >> >> Let's get a reasonable feature set implemented and then come back in 8.6 >> to improve it. For example, there is no need for a special >> 'replication' user (just use super-user), and monitoring should be >> minimal until we have field experience of exactly what monitoring we >> need. >> >> The final commit-fest is in 5 days --- this is not the time for design >> discussion and feature additions. If we wait for SR to be feature >> complete, with design discussions, etc, we will hopelessly delay 8.5 and >> people will get frustrated. I am not saying we can't talk about design, >> but none of this should be a requirement for 8.5. > > We can't add monitoring until we know what the performance > characteristics are. Hmmm. And how will we know what the performance > characteristics are, I wonder? well I would say we do exactly how we have done in the past with other features - by debugging the stuff with low level tools until we fully understand what it really is and then we can always add more "accessible" stats. Stefan -- 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 12 Jan 2010 16:34 Tom Lane wrote: > Bruce Momjian <bruce(a)momjian.us> writes: > > The final commit-fest is in 5 days --- this is not the time for design > > discussion and feature additions. > > +10 --- the one reason I can see for deciding to bounce SR is that there > still seem to be design discussions going on. It is WAY TOO LATE for > that folks. It's time to be thinking "what's the least we have to do to > make this shippable?" I didn't know the plus meter went that high. ;-) LOL -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- 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 12 Jan 2010 16:35 Stefan Kaltenbrunner wrote: > >> Let's get a reasonable feature set implemented and then come back in 8.6 > >> to improve it. For example, there is no need for a special > >> 'replication' user (just use super-user), and monitoring should be > >> minimal until we have field experience of exactly what monitoring we > >> need. > >> > >> The final commit-fest is in 5 days --- this is not the time for design > >> discussion and feature additions. If we wait for SR to be feature > >> complete, with design discussions, etc, we will hopelessly delay 8.5 and > >> people will get frustrated. I am not saying we can't talk about design, > >> but none of this should be a requirement for 8.5. > > > > We can't add monitoring until we know what the performance > > characteristics are. Hmmm. And how will we know what the performance > > characteristics are, I wonder? > > well I would say we do exactly how we have done in the past with other > features - by debugging the stuff with low level tools until we fully > understand what it really is and then we can always add more > "accessible" stats. Right, so what is the risk of shipping without any fancy monitoring? -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- 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: "Joshua D. Drake" on 12 Jan 2010 16:36 On Tue, 2010-01-12 at 16:34 -0500, Bruce Momjian wrote: > Tom Lane wrote: > > Bruce Momjian <bruce(a)momjian.us> writes: > > > The final commit-fest is in 5 days --- this is not the time for design > > > discussion and feature additions. > > > > +10 --- the one reason I can see for deciding to bounce SR is that there > > still seem to be design discussions going on. It is WAY TOO LATE for > > that folks. It's time to be thinking "what's the least we have to do to > > make this shippable?" > > I didn't know the plus meter went that high. ;-) LOL Well, it is Tom. He has karma points. JD -- 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. -- 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 12 Jan 2010 17:26
> Right, so what is the risk of shipping without any fancy monitoring? We add monitoring in 9.1. er, 8.6. --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 |