Russell Smith <mr-russ@pws.com.au> writes:
> Tom Lane wrote:
>> What is happening is that during that 30-second wait, the bgwriter is
>> dumping out all the dirty pages, and acquiring open file references
>> to each segment of table "foo" as it does so. The VACUUM then truncates
>> "foo" back to zero size, since it contains no data after the DELETE,
>> and then the second INSERT bulks it up again. The problem is that the
>> bgwriter still has open file references to the deleted segments after
>> the first one, and that's where it'll write the data if given a chance.
>> So the updates disappear into the ether as far as any other process is
>> concerned, for each segment except the first.
>>
> Does TRUNCATE suffer from the same issue?
No, because TRUNCATE actually substitutes new physical files with
different relfilenode numbers, in order to allow rollback if its
transaction aborts. VACUUM is at risk, and I think we also use a
non-transactional truncate for temp tables, but those shouldn't be at
risk either.
> Seems reasonable from my lowly user point of view. Would there be a
> requirement to remove the extra segments at any point in the future or
> would they hang around on the disk forever?
I'm envisioning that they'd stay there as long as the table exists
(though I suppose a TRUNCATE could get rid of 'em). Zero-size files
shouldn't be a big problem...
regards, tom lane