Re: [HACKERS] Why copy_relation_data only use wal whenWALarchivingis enabled

Tom Lane wrote:
> Heikki Linnakangas <heikki(at)enterprisedb(dot)com> writes:
>> The best I can think of is to rename the obsolete file to
>> <relfilenode>.stale, when it's scheduled for deletion at next
>> checkpoint, and check for .stale-suffixed files in GetNewRelFileNode,
>> and delete them immediately in DropTableSpace.
>
> This is getting too Rube Goldbergian for my tastes. What if we just
> make DROP TABLESPACE force a checkpoint before proceeding?

Patch attached.

The scenario we're preventing is still possible if for some reason the
latest checkpoint record is damaged, and we start recovery from the
previous checkpoint record. I think the probability of that happening,
together with the OID wrap-around and hitting the relfilenode of a
recently deleted file with a new one, is low enough to not worry about.
If we cared, we could fix it by letting the files to linger for two
checkpoint cycles instead of one.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com