Hi,
This is my opinion, tell me if I am wrong.
the backup runs at 00:30. At that time, i am sure nobody use the
program which use postgres, so there is no transaction which store
would be a problem when cobian creates the snapshot.
Cobian started one day to create the backup but the volume was ful
On Fri, Jun 18, 2010 at 4:55 AM, Felde Norbert wrote:
> Hi,
>
> This are the informations I could collect:
>
>
> We use cobian to create the backup.
> There are two volumes in use, on C is the volume where everything is
> installed and here is the postgres data dir too.
> The postgres backup that
Hi,
This are the informations I could collect:
We use cobian to create the backup.
There are two volumes in use, on C is the volume where everything is
installed and here is the postgres data dir too.
The postgres backup that runs everynight places the backup file on
this volume too, it runs bef
On Thu, Jun 17, 2010 at 4:51 PM, Felde Norbert wrote:
> The first error message was what I got after postgres crashed and I
> tried to make a dump, run vacuum or tried somthing else.
> The second message I got when I tried to repaire the problem, so it
> dous not matter because I did something wro
The first error message was what I got after postgres crashed and I
tried to make a dump, run vacuum or tried somthing else.
The second message I got when I tried to repaire the problem, so it
dous not matter because I did something wrong i see.
If I could choose I would use a linux server too, bu
Subject: Re: [GENERAL] postgres crash SOS
>
> On Thu, Jun 17, 2010 at 2:53 PM, Tom Lane wrote:
> > You weren't too specific about how you got into this state, but I
> > suppose that it must have been a system crash or power failure. Even
> > then, you would not have gotten
On Thu, Jun 17, 2010 at 2:53 PM, Tom Lane wrote:
> You weren't too specific about how you got into this state, but I
> suppose that it must have been a system crash or power failure. Even
> then, you would not have gotten burnt if the filesystem and hardware
> did what they're supposed to do. I
"Joshua D. Drake" writes:
> On Thu, 2010-06-17 at 19:27 +, Dann Corbit wrote:
>>> (Perhaps more to the point, if they don't have problems, it's likely
>>> because they tell their customers how to configure Windows boxes safely
>>> before the fact. And people who are spending the money for an
On Thu, 2010-06-17 at 19:27 +, Dann Corbit wrote:
> > -Original Message-
> > From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> > Sent: Thursday, June 17, 2010 12:20 PM
> > To: Dann Corbit
> > Cc: Felde Norbert; pgsql-general@postgresql.org; Scott Marlowe
>
> -Original Message-
> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> Sent: Thursday, June 17, 2010 12:20 PM
> To: Dann Corbit
> Cc: Felde Norbert; pgsql-general@postgresql.org; Scott Marlowe
> Subject: Re: [GENERAL] postgres crash SOS
>
> Dann Corbit writes:
> &
On Thu, Jun 17, 2010 at 1:19 PM, Tom Lane wrote:
> (Perhaps more to the point, if they don't have problems, it's likely
> because they tell their customers how to configure Windows boxes safely
> before the fact. And people who are spending the money for an Oracle
> license will heed that advice.
Dann Corbit writes:
>> (Personally I'd never run a database I cared about on Windows.)
> Somehow, I doubt that Windows is to blame. For instance, Oracle and
> SQL*Server seem to run fine on Windows without this sort of problem.
Really? Are you front-line support for either, so that you can sa
> -Original Message-
> From: pgsql-general-ow...@postgresql.org [mailto:pgsql-general-
> ow...@postgresql.org] On Behalf Of Tom Lane
> Sent: Thursday, June 17, 2010 11:54 AM
> To: Felde Norbert
> Cc: pgsql-general@postgresql.org; Scott Marlowe
> Subject: Re: [GENERA
Felde Norbert writes:
> The message is the same for the original pg_clog/0003, the 0003
> containing binary 0 and after pg_resetxlog:
> pg_dump: Error message from server: ERROR: could not access status of
> transaction 3974799
> DETAIL: Could not read from file "pg_clog/0003" at offset 204800:
On Thu, Jun 17, 2010 at 10:35 AM, Merlin Moncure wrote:
> On Thu, Jun 17, 2010 at 4:47 AM, Felde Norbert wrote:
>> Before I began I made a filesystem level backup after I stopped the
>> postgres service.
>> I have the original 0003 file, the size is 204800, The size of the
>> other files in this
On Thu, Jun 17, 2010 at 4:47 AM, Felde Norbert wrote:
> Before I began I made a filesystem level backup after I stopped the
> postgres service.
> I have the original 0003 file, the size is 204800, The size of the
> other files in this dir is 262144.
hm...any indication of why the file is small? r
Before I began I made a filesystem level backup after I stopped the
postgres service.
I have the original 0003 file, the size is 204800, The size of the
other files in this dir is 262144.
I corrected the permissions of the whole data dir, but the error
message is the same.
The exact messages:
The
On Wed, Jun 16, 2010 at 7:55 PM, Felde Norbert wrote:
> Hi all,
>
> I use 8.2 on a windows server 2008.
> Suddenly postgres crashed and I can not do anything. The message is
> Could not access status of transaction 3982736.
> DATAIL: Could not read from file "pg_clog/0003" at offset 204800: No err
On Wed, Jun 16, 2010 at 5:55 PM, Felde Norbert wrote:
> Hi all,
>
> I use 8.2 on a windows server 2008.
> Suddenly postgres crashed and I can not do anything. The message is
> Could not access status of transaction 3982736.
> DATAIL: Could not read from file "pg_clog/0003" at offset 204800: No err
Hi all,
I use 8.2 on a windows server 2008.
Suddenly postgres crashed and I can not do anything. The message is
Could not access status of transaction 3982736.
DATAIL: Could not read from file "pg_clog/0003" at offset 204800: No error.
The only one thing I found to correct this is to create a fil
20 matches
Mail list logo
