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 [t...@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; Vladimir Kosilov Subject: Re: [BUGS] BUG #7819: missing chunk number 0 for toast value 1235919 in pg_toast_35328 Pius Chan <pc...@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 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.1359747...@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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
