Re: Why copy_relation_data only use wal whenWALarchivingis enabled

Simon Riggs wrote:
> On Wed, 2007-10-17 at 15:02 +0100, Heikki Linnakangas wrote:
>> Simon Riggs wrote:
>>> If you've got a better problem statement it would be good to get that
>>> right first before we discuss solutions.
>> Reusing a relfilenode of a deleted relation, before next checkpoint
>> following the commit of the deleting transaction, for an operation that
>> doesn't WAL log the contents of the new relation, leads to data loss on
>> recovery.
> 
> OK, thanks. 
> 
> I wasn't aware we reused refilenode ids. The code in GetNewOid() doesn't
> look deterministic to me, or at least isn't meant to be.
> GetNewObjectId() should be cycling around, so although the oid index
> scan using SnapshotDirty won't see committed deleted rows that shouldn't
> matter for 2^32 oids. So what gives?

I don't think you still quite understand what's happening. GetNewOid()
is not interesting here, look at GetNewRelFileNode() instead. And
neither are snapshots or MVCC visibility rules.

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