Thread: pg_clog problems

Hi everyone.

I'm having problems with a database, I get the following errors while accesing it (from my application and from pg_dump)

ERROR: Could not access status of transaction 65536
DETAIL: Could not read from file /usr/share/postgresql/data/pg_clog/0000 at offset 16384: No error.

I'm using postgreSQL 7.4RC2 under cygwin (on winxp). It probably got damagged because of a bad windows shutdown or something.

My question is, is there a way to reinit pg_clog files? I had read somewhere about something called pgsql_fsck or something, would this tool fix the problem? (if yes, please tell me the correct name )

Thanks in advance.

On Wed, Nov 19, 2003 at 01:45:21PM -0300, Franco Bruno Borghesi wrote:
> Hi everyone.
>
> I'm having problems with a database, I get the following errors while
> accesing it (from my application and from pg_dump)
>
> ERROR: Could not access status of transaction 65536
> DETAIL: Could not read from file /usr/share/postgresql/data/pg_clog/0000
> at offset 16384: No error.
>
> I'm using postgreSQL 7.4RC2 under cygwin (on winxp). It probably got
> damagged because of a bad windows shutdown or something.
>
> My question is, is there a way to reinit pg_clog files? I had read
> somewhere about something called pgsql_fsck or something, would this
> tool fix the problem? (if yes, please tell me the correct name ;) )

Simply create the clog file as 256K of zeros. If it's missing you need to
create it. But you really shouldn't be missing it since it's the first one
created. You didn't delete anything by accident?

Hpoe this helps,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> "All that is needed for the forces of evil to triumph is for enough good
> men to do nothing." - Edmond Burke
> "The penalty good people pay for not being interested in politics is to be
> governed by people worse than themselves." - Plato

The file was there, but maybe some blocks where missed (it's a fat32 fs).
Finally I reinstalled the database and the problem got solved, but now I know what to do for the next time

Thanks Martijn.


On Wed, 2003-11-19 at 21:31, Martijn van Oosterhout wrote:

On Wed, Nov 19, 2003 at 01:45:21PM -0300, Franco Bruno Borghesi wrote:
> Hi everyone.
> 
> I'm having problems with a database, I get the following errors while
> accesing it (from my application and from pg_dump)
> 
> ERROR: Could not access status of transaction 65536
> DETAIL: Could not read from file /usr/share/postgresql/data/pg_clog/0000
> at offset 16384: No error.
> 
> I'm using postgreSQL 7.4RC2 under cygwin (on winxp). It probably got
> damagged because of a bad windows shutdown or something.
> 
> My question is, is there a way to reinit pg_clog files? I had read
> somewhere about something called pgsql_fsck or something, would this
> tool fix the problem? (if yes, please tell me the correct name ;) )

Simply create the clog file as 256K of zeros. If it's missing you need to
create it. But you really shouldn't be missing it since it's the first one
created. You didn't delete anything by accident?

Hpoe this helps,

On Thu, Nov 20, 2003 at 10:48:08AM -0300, Franco Bruno Borghesi wrote:
> The file was there, but maybe some blocks where missed (it's a fat32
> fs).
> Finally I reinstalled the database and the problem got solved, but now I
> know what to do for the next time :P

Doh ...  Don't run your database in a FAT filesystem if you value your data!
It's probably as unreliable as it can get, and slow too.

--
Alvaro Herrera (<alvherre[@]dcc.uchile.cl>)
"La principal caracter�stica humana es la tonter�a"
(Augusto Monterroso)

don't worry!! it's just a cygwin installation for a demostration application for the sales team. Real application runs on bsd

On Thu, 2003-11-20 at 11:23, Alvaro Herrera Munoz wrote:

On Thu, Nov 20, 2003 at 10:48:08AM -0300, Franco Bruno Borghesi wrote:
> The file was there, but maybe some blocks where missed (it's a fat32
> fs).
> Finally I reinstalled the database and the problem got solved, but now I
> know what to do for the next time :P

Doh ...  Don't run your database in a FAT filesystem if you value your data!
It's probably as unreliable as it can get, and slow too.