-----Original Message-----
From: Andy Colson [mailto:andy@squeakycode.net]
Ow Mun Heng wrote:
>> I was playing around with dbi-link, hoping to get it connected to a
>teradata
>> database. However, before I dive into that, I figured that I might as
>well
>> try it out first on a PG Database (on another server)
>>
>> I did a select on a 30GB table and it froze the Originating database and
>it
>> ALSO froze the foreign database.
>>
>That looks like it came from dmesg. Did you look in the postgres log?
>
>"froze" is not a helpful description. PG spawns off a client for each
>connection, and I doubt one client could freeze another. So was the one
>connection froze, all PG clients froze, or the entire computer froze?
>
>You said you had to reboot, so I assume the entire computer.
>
>On the foreign box, have you ever pushed a large amount of data over the
>network? You might wanna try to copy some really big files a few times and
>see if you get the eth0 timeout error again.
>
>I assume you are using Linux and a new version of PG, right?
Sorry, I don't know how else to describe it cos I don't much activity over
my ssh connections. Even top refused to work on the foreign box.
Yeah, the foreign box has handled large amount of data before. I pushed out
over 300G of data while rsyncing the db to another slave.
Centos -5.2 and PG 8.3.7 on the foreign box and 8.3.12 on the originating
box.
I was told that I shouldn't use the views directly. I believe libpq or
something just tried to push out all 30G of data all at once from the
foreign box to the originating box.
After I used the remote_select functions. All is better (for now)
Thanks