Re: BUG #7819: missing chunk number 0 for toast value 1235919 in pg_toast_35328

Tom,

Thanks for your prompt response. Yeah, I should have provided you with my testing scripts. BTW, during numerous tests, I felt that if there is no long holding transaction (the one used for middle-tier service master/slave failover), the database server is much quicker to recover the space left by dead-row and it is also hard to make the TOAST area grow. Therefore, it is hard for me to reproduce the ERROR if there is no long-holding open transaction. Do you have any insight to it?

Regards,

Pius
________________________________________
From: Tom Lane [tgl(at)sss(dot)pgh(dot)pa(dot)us]
Sent: Friday, February 01, 2013 11:41 AM
To: Pius Chan
Cc: pgsql-bugs(at)postgresql(dot)org; Frank Moi; Ken Yu; Vincent Lasmarias; Vladimir Kosilov
Subject: Re: [BUGS] BUG #7819: missing chunk number 0 for toast value 1235919 in pg_toast_35328

Pius Chan <pchan(at)contigo(dot)com> writes:
> The ERROR happened again. After several days of investigation and testing, I can now reproduce the ERROR in my testing environment. The reason why the ERROR used to happen in a certain time period is that our report batch jobs run in that period and the batch job can make the TOAST area grow. I can repeat the ERROR with this set up and testing procedure.

Thanks. It would've been easier if you'd provided a more concrete test
procedure, but I've been able to reproduce what seems to be the same
failure. I don't know exactly what to do about it yet :-( --- see
http://www.postgresql.org/message-id/20362.1359747327@sss.pgh.pa.us

At the moment it appears to me that this error could only occur in
CLUSTER or its close cousin VACUUM FULL; ordinary database queries could
not see such a failure. Does that agree with your experience? If so,
this isn't really a data loss bug, so you should be able to just live
with it until we can work out a fix.

regards, tom lane