On Tue, Feb 21, 2012 at 1:46 PM, Maxim Boguk
<maxim.boguk@gmail.com> wrote:
On Tue, Feb 21, 2012 at 1:37 PM, Tom Lane
<tgl@sss.pgh.pa.us> wrote:
Maxim Boguk <
maxim.boguk@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
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.
