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

Pius Chan <pchan(at)contigo(dot)com> writes:
> 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?

I think the proximate cause is probably this case mentioned in
GetOldestXmin's comments:

* if allDbs is FALSE and there are no transactions running in the current
* database, GetOldestXmin() returns latestCompletedXid. If a transaction
* begins after that, its xmin will include in-progress transactions in other
* databases that started earlier, so another call will return a lower value.

So the trouble case is where autovacuum on the toast table starts at an
instant where nothing's running in the "test" database, but there are
pre-existing transaction(s) in the other database. Then later CLUSTER
starts at an instant where transactions are running in "test" and their
xmins include the pre-existing transactions.

So you need long-running transactions in another DB than the one where
the vacuuming/clustering action is happening, as well as some unlucky
timing. Assuming my theory is the correct one, of course.

regards, tom lane