larry price wrote:
On 12/19/05, Matthew Jarvis <[EMAIL PROTECTED]> wrote:
Anyhoo, last Thurs for the first time since I've been here (about 5 mo)
that data transfer didn't complete.
Have you figured out why it didn't complete?
No idea... I did notice that when I tried to manually ftp uplo
For better or worse the update process uses a DELETE then COPY
sequence to update the tables on the site. The DELETE takes place,
table is updated, next DELETE, next table etc sometimes the
process isn't being completed as though something is timing out, so I
was looking to a) speed up th
On 12/19/05, Matthew Jarvis <[EMAIL PROTECTED]> wrote:
> Anyhoo, last Thurs for the first time since I've been here (about 5 mo)
> that data transfer didn't complete.
Have you figured out why it didn't complete?
> For better or worse the update process uses a DELETE then COPY sequence
> to update
larry price wrote:
You're running the postgres client (psql) locally
using the database webbikedata as user bikefriday on host bikefriday.com
and you are feeding the file webtrans.sql to the client.
speed probably isn't an issue in most cases, copying the file in bulk
and then executing it's c
On 12/19/05, Matthew Jarvis <[EMAIL PROTECTED]> wrote:
> Looking at the following code in a sh file on one of our servers (I've
> snipped nonrelavant stuff):
>
> #!/bin/sh
> OUT_TO=/home/postgres/tmp/webtrans.sql
>
> #load the data to the destination DB
> DST_DB=webbikedata
> DST_IP=bikefriday.com
Looking at the following code in a sh file on one of our servers (I've
snipped nonrelavant stuff):
#!/bin/sh
OUT_TO=/home/postgres/tmp/webtrans.sql
#load the data to the destination DB
DST_DB=webbikedata
DST_IP=bikefriday.com
DST_USER=bikefriday
/usr/local/pgsql/bin/psql $DST_DB -U $DST_USER -