Subject: Re: PATCH: Exclude unlogged tables from base backups
To: Andres Freund <andres@anarazel.de>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
References: <04791bab-cb04-ba43-e9c0-664a4c1ffb2c@pgmasters.net>
 <20171212225234.jqdwd4sp663l4znp@alap3.anarazel.de>
 <5e428ad7-f37f-6479-aabf-2c8b9318fb79@pgmasters.net>
 <20171212230740.evr7rvkzz5bztdg6@alap3.anarazel.de>
From: David Steele <david@pgmasters.net>
Message-ID: <35ea14df-e481-34d5-b636-35038dd568a3@pgmasters.net>
Date: Tue, 12 Dec 2017 18:18:09 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0)
 Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <20171212230740.evr7rvkzz5bztdg6@alap3.anarazel.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 12/12/17 6:07 PM, Andres Freund wrote:
>>
>> I don't see this as any different than what happens during recovery. The
>> unlogged forks are cleaned / re-inited before replay starts which is the
>> same thing we are doing here.
> 
> 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...

-- 
-David
david@pgmasters.net