* Jeff Davis <pg...@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, ai...@highrise.ca command like a king, http://www.highrise.ca/ work like a slave.
signature.asc
Description: Digital signature
