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