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 ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
