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

From Brandon Aiken
Subject Re: could not write to log -> PANIC -> System down
Date
Msg-id F8E84F0F56445B4CB39E019EF67DACBA40165C@exchsrvr.winemantech.com
Whole thread Raw
In response to Re: could not write to log -> PANIC -> System down  ("Merlin Moncure" <mmoncure@gmail.com>)
Responses Re: could not write to log -> PANIC -> System down
List pgsql-general
That should not occur if NetBackup is at all a recent version and you're
on WinXP or Win2k3.  The backup client should be using Volume Shadow
Copy.  You should only have file locking issues on Windows 2000 or if
your partitions are FAT32 (which is a terrible idea).

Of course, it's Windows.  "Should not" is often a suggestion, it seems.
As a port, postmaster.exe was presumably not written with VSS in mind,
so it might object to the shadow copy instantiation (which, again, it
*should* not be able to do).

No idea on the frequent autovacuuming.  Do you do a lot of deletes?

--
Brandon Aiken
CS/IT Systems Engineer

-----Original Message-----
From: pgsql-general-owner@postgresql.org
[mailto:pgsql-general-owner@postgresql.org] On Behalf Of Merlin Moncure
Sent: Thursday, December 14, 2006 4:00 PM
To: Scott Marlowe
Cc: dev; pgsql general
Subject: Re: [GENERAL] could not write to log -> PANIC -> System down

On 12/14/06, Scott Marlowe <smarlowe@g2switchworks.com> wrote:
>
>
>
> 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

>  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.
>

problem is veritas which has a special kernel driver which can lock
any file even if it is in use by an application.  obviously, you do
not want to do raw file system backup of your database folder.

I would check out eSilo (disclaimer: I work at this company) for
backup solutions that are specialized towards databases.

merlin

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
       subscribe-nomail command to majordomo@postgresql.org so that your
       message can get through to the mailing list cleanly

pgsql-general by date:

Previous
From: Glen Parker
Date:
Subject: PITR / what directories/files can be ignored?
Next
From: Martijn van Oosterhout
Date:
Subject: Re: could not write to log -> PANIC -> System down