On 02/20/2012 07:46 PM, Maxim Boguk wrote:
On Tue, Feb 21, 2012 at 1:37 PM, Tom Lane <t...@sss.pgh.pa.us
<mailto:t...@sss.pgh.pa.us>> wrote:
Maxim Boguk <maxim.bo...@gmail.com <mailto:maxim.bo...@gmail.com>>
writes:
>> Do you know why the mod date on the file is 2012-02-20 12:04?
> Cron was attempt to populate the table once per hour after that
problem
> happened.
> And each time it was produced the same error.
That's interesting ... is there any possibility that the
insertions were
attempting to insert values that matched a previously-existing primary
key value? I'm thinking there's no reason for the INSERT per se to be
touching nonexistent blocks, but if for some reason the pkey index
still
had entries pointing at vanished rows (as it seems to) then the errors
could be coming from uniqueness checks attempting to fetch those
rows to
see if they're live.
regards, tom lane
Hi,
There isn't possibility but close to 100% new inserted values were
matched a previously-existing primary
key value.
The table is hand-made 'materialyzed view'-type statistic table which
is getting recalculated via cron.
--
Maxim Boguk
Senior Postgresql DBA.
Sorry Maxim,
Trying to follow along here: Are you say the inserted record DO or DO
NOT match previously existing key values.
