On 02/20/2012 07:46 PM, Maxim Boguk wrote:
>
>
> On Tue, Feb 21, 2012 at 1:37 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us
> <mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us>> wrote:
>
> Maxim Boguk <maxim(dot)boguk(at)gmail(dot)com <mailto: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.
>
> --
> 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.