Re: BUG #10095: primary key corruption
От | Luke Coldiron |
---|---|
Тема | Re: BUG #10095: primary key corruption |
Дата | |
Msg-id | BAY172-W52B11170CCDD6711EF9D60C6590@phx.gbl обсуждение исходный текст |
Ответ на | Re: BUG #10095: primary key corruption (Matheus de Oliveira <matioli.matheus@gmail.com>) |
Список | pgsql-bugs |
On Mon=2C Apr 21=2C 2014 at 5:08 PM=2C <lukecoldiron@hotmail.com> wrote: =0A= =0A= =0A= ERROR: could not read block 0 in file "base/16407/41243": read only 0 of =0A= 8192 bytes =0A= Is this server a slave? Or has it been at some point (and now promoted to m= aster)? It is not a slave server nor has it been at any point in time. =0A= =0A= =0A= When I look on the filesystem the "base/16407/41243" file is zero bytes. =0A= When I lookup the object name that is currupt via select relname from =0A= pg_class where relfilenode =3D 41243=3B it is always a primary key and not =0A= always on the same table. =0A= For now=2C you can fix the corrupted indexes by simple issuing REINDEX. Alt= hough I strongly recommend you doing a dump of all your databases=2C remove= it all and execute initdb again=2C and then restore the dumps. =0A= =0A= =0A= The system was previously upgraded from pg 8.3.7 and these issues did not =0A= occur. How have you managed the upgrade? Also=2C has been any hardware issue recen= tly? I also recommend you checking for disk and memory corruption. I need to give a little more background on this. The database is installed = standalone on many different hardware instances that are exactly the same. = The database is used for configuration in a closed software appliance much = like a consumer router. Acceptance testing of a fresh (no upgrade) pg 9.3.3= database instance has yielded a number of units with the primary key corru= ption issue after running for a short period of time (within a week of test= ing operation). As shown from the error message above the file that should = hold the primary key is truncated. The table corresponding to this also con= tains zero rows but is not corrupt and is expected to have zero rows. I am = suspecting a change in some behavior between pg 8.3.7 and 9.3.3 as the caus= e everything else being equal. At the moment I don't have much to go on as = I have not been able to reproduce the issue on demand however I am still wo= rking at trying to be a reproducible test case.=0A= =0A= Best regards=2C --=20 Matheus de Oliveira Analista de Banco de Dados Dextra Sistemas - MPS.Br n=EDvel F! www.dextra.com.br/postgres =0A= =0A= =0A= =
В списке pgsql-bugs по дате отправления: