Hi:

I've migrated a couple of weeks ago from 7.4.2 to 7.4.5 and I am getting
this error after executing a query:

Warning: pg_exec() query failed: ERROR: could not access status of
transaction 4244329 in /home/wisconsin/www/_proc/bbdd/_c_bbdd.php on
line 160
ERROR ACCESO BASE DE DATOSERROR: could not access status of
transaction 4244329

I tried VACCUM:

wisconsin=# VACUUM ANALYZE verbose movimientos_c_c;
INFO: vacuuming "public.movimientos_c_c"
INFO: index "movimientos_c_cod_movimient_key" now contains 3658193
row versions in 13316 pages
DETAIL: 1397781 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 0.95s/7.85u sec elapsed 90.56 sec.
INFO: index "movimientos_c_c_i01" now contains 3658193 row versions
in 24737 pages
DETAIL: 1397781 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 1.57s/7.28u sec elapsed 126.50 sec.
INFO: "movimientos_c_c": removed 1397781 row versions in 56621 pages
DETAIL: CPU 2.93s/5.94u sec elapsed 60.67 sec.
INFO: index "movimientos_c_cod_movimient_key" now contains 2260414
row versions in 13316 pages
DETAIL: 1397780 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 1.07s/6.40u sec elapsed 140.73 sec.

INFO: index "movimientos_c_c_i01" now contains 2260414 row versions
in 24737 pages
DETAIL: 1397780 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 1.62s/6.27u sec elapsed 199.39 sec.
INFO: "movimientos_c_c": removed 1397780 row versions in 56642 pages
DETAIL: CPU 2.85s/5.98u sec elapsed 66.71 sec.
INFO: index "movimientos_c_cod_movimient_key" now contains 862646
row versions in 13316 pages
DETAIL: 1397769 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 1.00s/5.21u sec elapsed 136.48 sec.
INFO: index "movimientos_c_c_i01" now contains 862646 row versions
in 24737 pages
DETAIL: 1397769 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 1.72s/5.13u sec elapsed 212.03 sec.
INFO: "movimientos_c_c": removed 1397769 row versions in 56650 pages
DETAIL: CPU 2.76s/5.86u sec elapsed 45.32 sec.
ERROR: could not access status of transaction 4244329
DETAIL: could not open file "/usr/local/pgsql/data/pg_clog/0004": No
existe el fichero o el directorio

I tried reindexing:

DROP INDEX movimientos_c_c_i01;
CREATE INDEX movimientos_c_c_i01 ON movimientos_c_c (cod_empresa,
cod_per_emp, cod_movimiento, fecha_movimiento);

ERROR: could not access status of transaction 4244329
DETAIL: could not open file "/usr/local/pgsql/data/pg_clog/0004": No
existe el fichero o el directorio



Any help will be much appreciated.
Ruben.



---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

ruben20 (AT) superguai (DOT) com wrote:
[SNIP]

create a empty file:

# touch /usr/local/pgsql/data/pg_clog/0004

at this point postgres will complain about the fact that an offset is missing,

at this point fill with 0 your file ( blocks of 8K ) till reach that offset reclaimed.



Regards
Gaetano Mendola

"ruben20 (AT) superguai (DOT) com" <ruben20 (AT) superguai (DOT) com> writes:
What files actually appear in /usr/local/pgsql/data/pg_clog/ ?

The standard advice for working around this sort of thing is to create a
dummy pg_clog/0004 file and fill it with 256K of zeroes, so that the
VACUUM will decide that the affected row is dead. However it would be
a good idea to first try to understand what's gone wrong. Is this an
isolated dropped-bit in a transaction status field, or a symptom of more
general corruption in the table? You could try to determine which page
of the table contains the corrupted row, and then dump out that page
with pg_filedump for visual analysis. (See past discussions of
corrupted-data recovery in the list archives for details.)

regards, tom lane

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