aboutsummaryrefslogtreecommitdiff
path: root/src/tutorial/basics.source
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2006-11-20 01:07:56 +0000
committerTom Lane <tgl@sss.pgh.pa.us>2006-11-20 01:07:56 +0000
commit1a5c450f3024ac57cd6079186c71b3baf39e84eb (patch)
tree5c38669f870f990694459c09de39232fbbc4108b /src/tutorial/basics.source
parentd68efb3f8d868dc6bf4f86b8cdd5745b833b6dc4 (diff)
downloadpostgresql-1a5c450f3024ac57cd6079186c71b3baf39e84eb.tar.gz
postgresql-1a5c450f3024ac57cd6079186c71b3baf39e84eb.zip
When truncating a relation in-place (eg during VACUUM), do not try to unlink
any no-longer-needed segments; just truncate them to zero bytes and leave the files in place for possible future re-use. This avoids problems when the segments are re-used due to relation growth shortly after truncation. Before, the bgwriter, and possibly other backends, could still be holding open file references to the old segment files, and would write dirty blocks into those files where they'd disappear from the view of other processes. Back-patch as far as 8.0. I believe the 7.x branches are not vulnerable, because they had no bgwriter, and "blind" writes by other backends would always be done via freshly-opened file references.
Diffstat (limited to 'src/tutorial/basics.source')
0 files changed, 0 insertions, 0 deletions