To workaround the problem, I had to move the Director on the DB machine too.So now, the SD is still on Sun280R, all FD are around unchanged, and Director runs on the Solaris Intel together with Postgres, with a modified dir.conf to connect to the SD on the network.Maybe some bug with postgres whe
.wow.probably the bug is on the Intel installation where postgres now resides?But...I have plenty of Intel installations running postgres, and I usually have no problem using the DB from any host.Do you have any clue to workaround the bug?
Gabriele Bulfon - Sonicle S.r.l
On 9/12/06, Gabriele Bulfon <[EMAIL PROTECTED]> wrote:
iserver-dir: postgresql.c:77 db_open first timeiserver-dir: bsys.c:70 pthread_cond_timedwait sec=5 usec=0iserver-dir: bsys.c:77 pthread_cond_timedwait stat=145 ERR=Connection timed out
Huh... it seems the failure is during bmicrosleep(), when
I rised debug to 500.Before the I issue the "list volumes" on bconsole, I see a LOT LOT of debug about postgres selects going through very fine.Once I run the bconsole command I find this:iserver-dir: scheduler.c:253 enter find_runs()iserver-dir: scheduler.c:289 Got job: Enterprise Backupiserver-
On 9/12/06, MaxxAtWork <[EMAIL PROTECTED]> wrote:
> Sorry, I'm no expert in postgres but what I would do is:
> - check google results for that postgres error
> - sniff deeper the net and have a look at packet contents, first logging a
> successful connection (e.g. that one from psql) to see what i
On 9/12/06, Gabriele Bulfon <[EMAIL PROTECTED]> wrote:
Trying psql was the first check I did when I saw the problem.As you suggested, I tried with snoop, and verified that the 280 was actually connecting to the correct machine.
So, I looked into the postgres.log of the remote db machine...and fou
Trying psql was the first check I did when I saw the problem.As you suggested, I tried with snoop, and verified that the 280 was actually connecting to the correct machine.So, I looked into the postgres.log of the remote db machine...and found this :LOG: incomplete startup packetSo I monitor
On 9/11/06, Gabriele Bulfon <[EMAIL PROTECTED]> wrote:
The original setup was one Sun280R machine running all the daemons and postgres.
This machine is responsible for backups.
Because the DB is too slow, and slow down the overall backup
performance (from 10K it slows down to 1K...), I wanted to
On 11 Sep 2006 at 13:31, Gabriele Bulfon wrote:
> Hello,
> after discovering that Postgres is too slow on Sun 280R machines forBacula
> management, I decided to test one of them and have the PostgresDB run on
> another faster Solaris machine on the LAN.
> So I prepared the new DB from scratch, m
The original setup was one Sun280R machine running all the daemons and postgres.
This machine is responsible for backups.
Because the DB is too slow, and slow down the overall backup
performance (from 10K it slows down to 1K...), I wanted to move
Postgres.
So now, all bacula daemons are still run
Gabriele Bulfon <[EMAIL PROTECTED]> wrote:
> Hello,
> after discovering that Postgres is too slow on Sun 280R machines forBacula
> management, I decided to test one of them and have the PostgresDB run on
> another faster Solaris machine on the LAN.
> So I prepared the new DB from scratch, modifi
11 matches
Mail list logo
