Tom Lane wrote:
> Gaetano Mendola <mendola@bigfoot.com> writes:
>
>>Richard Huxton wrote:
>>
>>>If page number 8549 was the one being held, I don't think vacuum can
>>>truncate the file. The empty space can be re-used, but the rows can't be
>>>moved to a lower page while a transaction is using them.
>
>
>>It's clear now.
>
>
> Not entirely. VACUUM FULL doesn't really worry about whether anyone
> else "is using" the table --- it knows no one else is, because it holds
> exclusive lock on the table. However it must preserve dead tuples that
> would still be visible to any existing transaction, because that other
> transaction could come along and look at the table after VACUUM
> finishes and releases the lock.
>
> What really drives the process is that VACUUM FULL moves tuples in order
> to make the file shorter (release empty pages at the end) --- and not
> for any other reason. So it could stop when there is still plenty of
> dead space in the table. It stops when the last nonempty page contains
> a tuple that it can't find room for in any earlier page.
>
> What I suppose you saw was that page 8503 contained a tuple so large it
> wouldn't fit in the free space on any earlier page. By the time of the
> second vacuum, either this tuple was deleted, or deletion of some other
> tuples had made a hole big enough for it to fit in.
>
> The extent of the truncation in the second vacuum says that you had
> quite a lot of free space, so it's a bit surprising that there wasn't
> enough room in any one page for such a tuple to be moved, but that seems
> to be what happened.
All rows of that table are almost of the same size, so this is not the
reason, and neither any row was deleted.
May be the page 8503 was cointainig a dead row ?
I can send you off line another vacuum full sequence if you need it, I sent it
to list but apparently the size was too much and noone of you seen it.
Regards
Gaetano Mendola