Re: standby registration (was: is sync rep stalled?)

Поиск
Список
Период
Сортировка
От Greg Smith
Тема Re: standby registration (was: is sync rep stalled?)
Дата
Msg-id 4CACA32E.2020206@2ndquadrant.com
обсуждение исходный текст
Ответ на Re: standby registration (was: is sync rep stalled?)  (Josh Berkus <josh@agliodbs.com>)
Ответы Re: standby registration (was: is sync rep stalled?)  (Robert Haas <robertmhaas@gmail.com>)
Re: standby registration (was: is sync rep stalled?)  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Список pgsql-hackers
Josh Berkus wrote:
> However, I think we're getting way the heck away from how far we 
> really want to go for 9.1.  Can I point out to people that synch rep 
> is going to involve a fair bit of testing and debugging, and that 
> maybe we don't want to try to implement The World's Most Configurable 
> Standby Spec as a first step?

I came up with the following initial spec for Most Configurable Standby 
Setup Ever recently:

-The state of all available standby systems is exposed via a table-like 
interface, probably an SRF.
-As each standby reports back a result, its entry in the table is 
updated with what level of commit it has accomplished (recv, fsync, etc.)
-The table-like list of standby states is then passed to a function, 
that you could write in SQL or whatever else makes you happy.  The 
function returns a boolean for whether sufficient commit guarantees have 
been met yet.  You can make the conditions required as complicated as 
you like.
-Once that function returns true, commit on the master.  Otherwise 
return to waiting for standby responses.

So that's what I actually want here, because all subsets of it proposed 
so are way too boring.  If you cannot express every possible standby 
situation that anyone will ever think of via an arbitrary function hook, 
obviously it's not worth building at all.

Now, the more relevant question, what I actually need in order for a 
Sync Rep feature in 9.1 to be useful to the people who want it most I 
talk to.  That would be a simple to configure setup where I list a 
subset of "important" nodes, and the appropriate acknowledgement level I 
want to hear from one of them.  And when one of those nodes gives that 
acknowledgement, commit on the master happens too.  That's it.  For use 
cases like the commonly discussed "two local/two remote" situation, the 
two remote ones would be listed as the important ones.

Until something that simple is committed, tested, debugged, and had some 
run-ins with the real world, I have minimal faith that an attempt to 
anything more complicated has sufficient information to succeed.  And 
complete faith that even trying will fail to deliver something for 9.1.  
The scope creep that seems to be happening here in the name of "this 
will be hard to change so it must be right in the first version" boggles 
my mind.

-- 
Greg Smith, 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD
PostgreSQL Training, Services and Support  www.2ndQuadrant.us




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Dimitri Fontaine
Дата:
Сообщение: Re: Issues with Quorum Commit
Следующее
От: Robert Haas
Дата:
Сообщение: Re: patch: tsearch - some memory diet