Tom,
Thanks for your prompt response. Yeah, I should have provided you with my t=
esting scripts. BTW, during numerous tests, I felt that if there is no long=
holding transaction (the one used for middle-tier service master/slave fai=
lover), the database server is much quicker to recover the space left by de=
ad-row and it is also hard to make the TOAST area grow. Therefore, it is ha=
rd for me to reproduce the ERROR if there is no long-holding open transacti=
on. Do you have any insight to it?
Regards,
Pius
________________________________________
From: Tom Lane [tgl@sss.pgh.pa.us]
Sent: Friday, February 01, 2013 11:41 AM
To: Pius Chan
Cc: pgsql-bugs@postgresql.org; Frank Moi; Ken Yu; Vincent Lasmarias; Vladim=
ir Kosilov
Subject: Re: [BUGS] BUG #7819: missing chunk number 0 for toast value 12359=
19 in pg_toast_35328
Pius Chan <pchan@contigo.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 t=
he ERROR used to happen in a certain time period is that our report batch j=
obs run in that period and the batch job can make the TOAST area grow. I c=
an 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
