* Jeff Davis <pgsql@j-davis.com> [081212 13:41]:
> On Fri, 2008-12-12 at 08:57 -0500, Aidan Van Dyk wrote:
> > > For (2) we need a full interlock. Given that we don't currently support
> > > multiple streamed standby servers, it seems not much point in
> > > implementing the interlock (2) would require. Should we leave that part
> > > for 8.5, or do it now?
> >
> > Ugh... If all sync-rep is gong to give is "if it's working, the commit
> > made it the slaves, but it might not be working [anymore|yet], but you
> > (the app using pg) have no way of knowing...", that sort of defeats the
> > point ;-)
>
> http://archives.postgresql.org/pgsql-hackers/2008-12/msg00865.php
>
> Fujii Masao offers to provide a SQL function that will tell you
> definitively whether you are in full sync rep, or some degraded mode. I
> assume that there will also be server log messages to identify whether
> you ever left sync rep mode.
So when would I have to call that function? Before begin, after begin,
before commit, or all, to guarentee that know that my application is
suppose to "delay" calling commit until when sync-mode is actualyl
synchronous? And then afterwards, I have to call it again t omake sure
it didn't fall "out of" mode between my previous call and the commit
actually working?
Bugger it, then I'll have to to patch every single app/query that writes
transactions to the database to be "sync rep" aware... And if I miss
one...
Some might say that if the data's that important, that audit/patching to
be "sync rep" aware is worth it, but then I guess they say that then you
might as well do application level replication as well ;-)
a.
--
Aidan Van Dyk Create like a god,
aidan@highrise.ca command like a king,
http://www.highrise.ca/ work like a slave.
