[Pgpool-general] PgPool install, Part Deux

[Tim Ringenbach]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pgfoundry.org/pipermail/pgpool-general/attachments/20090714/a3baf186/attachment.html>