Neil Conway wrote: > On Fri, 2002-12-13 at 13:36, Jan Wieck wrote: > > But you cannot use the result of such a SELECT to update anything. So > > you can only phase out complete read only transaction to the slaves. > > Requires support from the application since the load balancing system > > cannot know automatically what will be a read only transaction and what > > not. > > Interesting -- SQL contains the concept of "read only" and "read write" > transactions (the default is RW). If we implemented that (which > shouldn't be too difficult[1]), it might make differentiating between > classes of transactions a little easier. Client applications would still > need to be modified, but not nearly as much. > > Does this sound like it's worth doing? > > [1] -- AFAICS, the only tricky implementation detail is deciding exactly > which database operations are "writes". Does nextval() count, for > example?
You can't migrate a session between nodes, so the entire _session_ has to be read-only. -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
