On 12/12/17 6:21 PM, Andres Freund wrote:
> On 2017-12-12 18:18:09 -0500, David Steele wrote:
>> On 12/12/17 6:07 PM, Andres Freund wrote:
>>>
>>> It's quite different - in the recovery case there's no other write
>>> activity going on. But on a normally running cluster the persistence of
>>> existing tables can get changed, and oids can get recycled. What
>>> guarantees that between the time you checked for the init fork the table
>>> hasn't been dropped, the oid reused and now a permanent relation is in
>>> its place?
>>
>> Well, that's a good point!
>>
>> How about rechecking the presence of the init fork after a main/other fork
>> has been found? Is it possible for an init fork to still be lying around
>> after an oid has been recycled? Seems like it could be...
>
> I don't see how that'd help. You could just have gone through this cycle
> multiple times by the time you get to rechecking. All not very likely,
> but I don't want us to rely on luck here...
Definitely not.
> If we had a way to prevent relfilenode reuse across multiple checkpoints
> this'd be easier, although ALTER TABLE SET UNLOGGED still'd complicate.
Or error the backup if there is wraparound?
We already have an error if a standby is promoted during backup -- so
there is some precedent.
> I guess we could have the basebackup create placeholder files that
> prevent relfilenode reuse, but that seems darned ugly.
Yes, very ugly.
--
-David
david@pgmasters.net