]> granicus.if.org Git - postgresql/commit
When a relation is moved to another tablespace, we can't assume that we can
authorHeikki Linnakangas <heikki.linnakangas@iki.fi>
Tue, 7 Oct 2008 11:16:01 +0000 (11:16 +0000)
committerHeikki Linnakangas <heikki.linnakangas@iki.fi>
Tue, 7 Oct 2008 11:16:01 +0000 (11:16 +0000)
commit1abe8ea3a6f8e36919d1f63f7d4a083204a75bf8
tree4a6e6a556a952ff476d04c3c36581c2c226c04bb
parentaaa0d6b8584490d8f503e8a9658926acd4f720fd
When a relation is moved to another tablespace, we can't assume that we can
use the old relfilenode in the new tablespace. There might be another relation
in the new tablespace with the same relfilenode, so we must generate a fresh
relfilenode in the new tablespace.

The 8.3 patch to let deleted relation files linger as zero-length files until
the next checkpoint made this more obvious: moving a relation from one table
space another, and then back again, caused a collision with the lingering
file.

Back-patch to 8.1. The issue is present in 8.0 as well, but it doesn't seem
worth fixing there, because we didn't have protection from OID collisions
after OID wraparound before 8.1.

Report by Guillaume Lelarge.
src/backend/commands/tablecmds.c