aboutsummaryrefslogtreecommitdiff
path: root/src/backend/executor/nodeRecursiveunion.c
diff options
context:
space:
mode:
authorHeikki Linnakangas <heikki.linnakangas@iki.fi>2008-10-07 11:15:41 +0000
committerHeikki Linnakangas <heikki.linnakangas@iki.fi>2008-10-07 11:15:41 +0000
commitfa3938fcb1c8e1e8d5da0e62dbf094f5f1c641c4 (patch)
treebda2e1b642b98c0b27b4f1fb8b0675172bd3c760 /src/backend/executor/nodeRecursiveunion.c
parent078aaf796eda274cd6cd241331278d4f089a6d7e (diff)
downloadpostgresql-fa3938fcb1c8e1e8d5da0e62dbf094f5f1c641c4.tar.gz
postgresql-fa3938fcb1c8e1e8d5da0e62dbf094f5f1c641c4.zip
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.
Diffstat (limited to 'src/backend/executor/nodeRecursiveunion.c')
0 files changed, 0 insertions, 0 deletions