Re: BUG #10095: primary key corruption

From: Luke Coldiron <lukecoldiron(at)hotmail(dot)com>
To: Matheus de Oliveira <matioli(dot)matheus(at)gmail(dot)com>
Cc: "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #10095: primary key corruption
Date: 2014-04-22 15:28:39
Message-ID: BAY172-W52B11170CCDD6711EF9D60C6590@phx.gbl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Mon, Apr 21, 2014 at 5:08 PM, <lukecoldiron(at)hotmail(dot)com> wrote:

ERROR: could not read block 0 in file "base/16407/41243": read only 0 of

8192 bytes

Is this server a slave? Or has it been at some point (and now promoted to master)?

It is not a slave server nor has it been at any point in time.

When I look on the filesystem the "base/16407/41243" file is zero bytes.

When I lookup the object name that is currupt via select relname from

pg_class where relfilenode = 41243; it is always a primary key and not

always on the same table.

For now, you can fix the corrupted indexes by simple issuing REINDEX. Although I strongly recommend you doing a dump of all your databases, remove it all and execute initdb again, and then restore the dumps.


The system was previously upgraded from pg 8.3.7 and these issues did not

occur.
How have you managed the upgrade? Also, has been any hardware issue recently? 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 corruption issue after running for a short period of time (within a week of testing operation). As shown from the error message above the file that should hold the primary key is truncated. The table corresponding to this also contains 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 cause 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 working at trying to be a reproducible test case.

Best regards,
--
Matheus de Oliveira
Analista de Banco de Dados
Dextra Sistemas - MPS.Br nível F!
www.dextra.com.br/postgres

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Bruce Momjian 2014-04-22 19:47:50 Re: BUG #9416: Setting up postgresql-9.1 (9.1.12-0wheezy1) Fails Configuration
Previous Message Matheus de Oliveira 2014-04-22 13:46:52 Re: BUG #10095: primary key corruption