On Tue, Feb 21, 2012 at 1:46 PM, Maxim Boguk <maxim(dot)boguk(at)gmail(dot)com> wrote:
>
>
> On Tue, Feb 21, 2012 at 1:37 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
>> Maxim Boguk <maxim(dot)boguk(at)gmail(dot)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.
>
>
To be clear - the new inserted values do match a previously-existing
primary key values almost always.
Sorry for not being clear.