Re: could not write to log -> PANIC -> System down - Mailing list pgsql-general

From Scott Marlowe
Subject Re: could not write to log -> PANIC -> System down
Date
Msg-id 1166118428.3243.176.camel@state.g2switchworks.com
Whole thread Raw
In response to could not write to log -> PANIC -> System down  ("dev" <dev@strategma.bg>)
Responses Re: could not write to log -> PANIC -> System down
List pgsql-general

On Thu, 2006-12-14 at 11:28, dev wrote:
> Hello friends,
>
> we have some strange problem, postmaster (pg 8.1 /win32)
> suddenly shutdown because of "no reason".
>
> The interesting thing is that this occurs always at
> almost same time (between 0.00 and 0.30h), in that time period is
> running system backup (Veristas backupexec agent) - starts at 23:30.
> The problem occurs randomly.
> In two of cases we have UPDATE/INSERT operation, but in third case - no.
>
> P.S. Why "autovacuum" runs every minute almost? Is this related?
>
> Thanks in advanced!
>
>
> ================ LOG (2006-12-14) ==================
> 2006-12-14 00:00:51 LOG:  autovacuum: processing database "mtdb"
>
> 2006-12-14 00:01:52 LOG:  autovacuum: processing database "mtdb"
>
> 2006-12-14 00:02:53 LOG:  autovacuum: processing database "mtdb"
>
> 2006-12-14 00:03:54 LOG:  autovacuum: processing database "mtdb"
>
> 2006-12-14 00:04:56 LOG:  autovacuum: processing database "mtdb"
>
> 2006-12-14 00:06:02 LOG:  autovacuum: processing database "mtdb"
>
> 2006-12-14 00:06:02 ERROR:  could not write block 14725 of relation
> 1663/16388/61387: Permission denied
>
> 2006-12-14 00:06:02 CONTEXT:  writing block 14725 of relation
> 1663/16388/61387

Looks like something is changing the permissions on this file or
something.

Is your backup agent (vertias backupexec) doing a file system backup of
the $PGDATA directory?  This is probably not a good idea, especially if
it changes perms / locks the files while it is doing a backup.  Either
way, a file system backup is not the proper way to backup a pgsql
instance, unless it is combined with PITR recovery.

Best answer is to not let the backup agent hit the $PGDATA directory,
but rather to run a backup with pg_dump or pg_dumpall to some other
directory and have your backup agent back that file up.

pgsql-general by date:

Previous
From: Ben
Date:
Subject: Re: a question for the way-back machine
Next
From: Richard Broersma Jr
Date:
Subject: Re: Are updateable view as a linked table in ms-access a bad idea?[solved]