[Pgpool-general] PgPool install, Part Deux

[Tatsuo Ishii]

I didn't think of #2. Interesting.
--
Tatsuo Ishii
SRA OSS, Inc. Japan

> Two random alternative ideas that probably suck:
> 1) Create your own alternative now() function that overrides the
> postgres one and calls back to pgpool to ask what to do
> 2) Use the RETURNING clause on the first backend to get the values
> actaully inserted for all the columns, then specify all of them for the
> other backends.
> 
> 
> Tatsuo Ishii wrote:
> > Yes, once I thought about the same idea...
> >
> > The major problem is the case now() is used as the default:
> >
> > CREATE TABLE t1(i TIMESTAMP DEFAULT CURRENT_TIMESTAMP, j INTEGER);
> > INSERT INTO t1(j) VALUES(1);
> >
> > In this case we need to rewrite the INSERT to:
> >
> > INSERT INTO t1(i,j) VALUES('2009-07-13 12:02:49.521097+04', 1);
> >
> > This is a little bit tricky...
> > --
> > Tatsuo Ishii
> > SRA OSS, Inc. Japan
> >
> >   
> >> 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 <ishii at 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 at pgfoundry.org
> > http://pgfoundry.org/mailman/listinfo/pgpool-general
> >   
> 
> 
> -- 
> Tim Ringenbach
> timr at asteriasgi.com
> 
> Asteria Solutions Group, Inc.
> http://www.asteriasgi.com
> 
> Office: 256.705.0287
> Main: 256.705.0277
> TollFree: 877-ASGI-4-ME
> Fax: 256.705.0280
>