Streaming replication status
in [PgSql]
|
From: Andrew Dunstan on 12 Jan 2010 09:13 Tom Lane wrote: > Fujii Masao <masao.fujii(a)gmail.com> writes: > >> I'm not sure whether poll(2) should be called for this purpose. But >> poll(2) and select(2) seem to often come together in the existing code. >> We should follow such custom? >> > > Yes. poll() is usually more efficient, so it's preferred, but not all > platforms have it. (On the other side, I think Windows might have > only poll and not select.) > > > No, other way around, I'm fairly sure. cheers andrew -- 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: Magnus Hagander on 12 Jan 2010 09:20 On Tue, Jan 12, 2010 at 15:13, Andrew Dunstan <andrew(a)dunslane.net> wrote: > > > Tom Lane wrote: >> >> Fujii Masao <masao.fujii(a)gmail.com> writes: >> >>> >>> I'm not sure whether poll(2) should be called for this purpose. But >>> poll(2) and select(2) seem to often come together in the existing code. >>> We should follow such custom? >>> >> >> Yes. poll() is usually more efficient, so it's preferred, but not all >> platforms have it. (On the other side, I think Windows might have >> only poll and not select.) >> >> >> > > No, other way around, I'm fairly sure. Yeah, the emulation layer has select, not poll. It basically translates the select into what looks very much like a poll, so maybe we should consider implementing poll as well/instead. But for now, select() is what we have. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- 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 12 Jan 2010 09:39 Magnus Hagander <magnus(a)hagander.net> writes: > On Tue, Jan 12, 2010 at 08:22, Heikki Linnakangas > <heikki.linnakangas(a)enterprisedb.com> wrote: >> Maybe we should just change the existing pg_current_xlog_location() >> function to return that when recovery is in progress. It currently >> throws an error during hot standby. > Not sure. I don't really like to monitor functions that return > different things depending on a scenario. Yeah. We should only use that function if we can define it to mean something on the slave that is very close to what it means on the master. Otherwise, pick another name. It seems to me that we should have at least two functions available on the slave: latest xlog location received and synced to disk by walreceiver (ie, we are guaranteed to be able to replay up to here); and latest xlog location actually replayed (ie, the state visible to queries on the slave). The latter perhaps could be pg_current_xlog_location(). 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: Stefan Kaltenbrunner on 12 Jan 2010 13:48 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. 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: Marko Kreen on 12 Jan 2010 15:06
On 1/12/10, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Fujii Masao <masao.fujii(a)gmail.com> writes: > > I'm not sure whether poll(2) should be called for this purpose. But > > poll(2) and select(2) seem to often come together in the existing code. > > We should follow such custom? > > > Yes. poll() is usually more efficient, so it's preferred, but not all > platforms have it. (On the other side, I think Windows might have > only poll and not select.) FYI: on PL/Proxy we use poll() exclusively and on platforms that dont have it (win32) we emulate poll() with select(): http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/plproxy/plproxy/src/poll_compat.c?rev=1.3&content-type=text/x-cvsweb-markup End result is efficient and clean #ifdef-less code. Something to consider. -- marko -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |