-----Original Message----- From: Andy Colson [mailto:andy@xxxxxxxxxxxxxxx] 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
