Re: [HACKERS] Why copy_relation_data only use wal whenWALarchiving is enabled
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? -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Why copy_relation_data only use wal whenWALarchiving is enabled
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. Or Performing non-WAL logged operations on a relation file leads to a truncated file on recovery, if the relfilenode of that file used to belong to a relation that was dropped after the last checkpoint. Happy? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
