Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Interesting failure mode. While reading it I was suddenly struck by the
> thought that overwriting storage managers may somehow be more resistent
> to these kind of failures. This may well be true, because there is
> never need for a VACUUM process whi
On Thu, Aug 18, 2005 at 03:48:55PM -0400, Tom Lane wrote:
> The only solution I can see (short of abandoning lazy VACUUM) is that
> we have to make the code that follows t_ctid chains more wary. That
> code is already aware (at least in the places I looked at) that a t_ctid
> link might lead to a
I believe I've traced down the cause of the Assert trap in VACUUM FULL
that Teodor reported here:
http://archives.postgresql.org/pgsql-hackers/2005-06/msg01278.php
The case that VACUUM is tripping up on is one in which some concurrent
transaction (call it X1) updates and then later deletes a row.
