Of course we dont.. And, what about intercepting the now() functions and make those timestamps to be generated by pgpool? It is, substitute this query: insert into insert into test values (1, now()); by: insert into test values (1, '2009-07-13 12:02:49.521097+04');
2009/7/13 Tatsuo Ishii <is...@sraoss.co.jp> > > > Basically, with your example, it is easy to see how now() could be a > > > problem, as if there is a slight delay on backend2 over backend1, the > dates > > > could / would drift some ... > > > > > > I tested that situation with an small table many days ago.. Sort of: > > > > create table test (a integer, b timestamp); > > insert into test values (1, now()); > > > > when i stated "select b from test;" in every node, i got indeed slightly > > different values, in thousandths of seconds.. > > Even more, when I executed the select through pgpool, it returned > different > > values on different sessions.. But pgpool anyway continued to work > > normally.. I thought that it would detect the data mismatch and degrade > one > > of the nodes... > > Actually long time ago once we did it (checks the actually returned > rows). What we found was, it's terribly slow. Do we want to do it > again? > -- > Tatsuo Ishii > SRA OSS, Inc. Japan >
_______________________________________________ Pgpool-general mailing list Pgpool-general@pgfoundry.org http://pgfoundry.org/mailman/listinfo/pgpool-general
