mirror of
https://github.com/postgres/postgres.git
synced 2026-03-28 05:13:33 -04:00
ffc226ab64
When I (rhaas) wrote the WAL summarizer code, I incorrectly believed that XLOG_SMGR_TRUNCATE truncates all forks to the same length. In fact, what other parts of the code do is compute the truncation length for the FSM and VM forks from the truncation length used for the main fork. But, because I was confused, I coded the WAL summarizer to set the limit block for the VM fork to the same value as for the main fork. (Incremental backup always copies FSM forks in full, so there is no similar issue in that case.) Doing that doesn't directly cause any data corruption, as far as I can see. However, it does create a serious risk of consuming a large amount of extra disk space, because pg_combinebackup's reconstruct.c believes that the reconstructed file should always be at least as long as the limit block value. We might want to be smarter about that at some point in the future, because it's always safe to omit all-zeroes blocks at the end of the last segment of a relation, and doing so could save disk space, but the current algorithm will rarely waste enough disk space to worry about unless we believe that a relation has been truncated to a length much longer than its actual length on disk, which is exactly what happens as a result of the problem mentioned in the previous paragraph. To fix, create a new visibilitymap helper function and use it to include the right limit block in the summary files. Incremental backups taken with existing summary files will still have this issue, but this should improve the situation going forward. Diagnosed-by: Oleg Tkachenko <oatkachenko@gmail.com> Diagnosed-by: Amul Sul <sulamul@gmail.com> Discussion: http://postgr.es/m/CAAJ_b97PqG89hvPNJ8cGwmk94gJ9KOf_pLsowUyQGZgJY32o9g@mail.gmail.com Discussion: http://postgr.es/m/6897DAF7-B699-41BF-A6FB-B818FCFFD585%40gmail.com Backpatch-through: 17
50 lines
1.9 KiB
C
50 lines
1.9 KiB
C
/*-------------------------------------------------------------------------
|
|
*
|
|
* visibilitymap.h
|
|
* visibility map interface
|
|
*
|
|
*
|
|
* Portions Copyright (c) 2007-2026, PostgreSQL Global Development Group
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
|
*
|
|
* src/include/access/visibilitymap.h
|
|
*
|
|
*-------------------------------------------------------------------------
|
|
*/
|
|
#ifndef VISIBILITYMAP_H
|
|
#define VISIBILITYMAP_H
|
|
|
|
#include "access/visibilitymapdefs.h"
|
|
#include "access/xlogdefs.h"
|
|
#include "storage/block.h"
|
|
#include "storage/buf.h"
|
|
#include "storage/relfilelocator.h"
|
|
#include "utils/relcache.h"
|
|
|
|
/* Macros for visibilitymap test */
|
|
#define VM_ALL_VISIBLE(r, b, v) \
|
|
((visibilitymap_get_status((r), (b), (v)) & VISIBILITYMAP_ALL_VISIBLE) != 0)
|
|
#define VM_ALL_FROZEN(r, b, v) \
|
|
((visibilitymap_get_status((r), (b), (v)) & VISIBILITYMAP_ALL_FROZEN) != 0)
|
|
|
|
extern bool visibilitymap_clear(Relation rel, BlockNumber heapBlk,
|
|
Buffer vmbuf, uint8 flags);
|
|
extern void visibilitymap_pin(Relation rel, BlockNumber heapBlk,
|
|
Buffer *vmbuf);
|
|
extern bool visibilitymap_pin_ok(BlockNumber heapBlk, Buffer vmbuf);
|
|
extern void visibilitymap_set(Relation rel,
|
|
BlockNumber heapBlk, Buffer heapBuf,
|
|
XLogRecPtr recptr,
|
|
Buffer vmBuf,
|
|
TransactionId cutoff_xid,
|
|
uint8 flags);
|
|
extern void visibilitymap_set_vmbits(BlockNumber heapBlk,
|
|
Buffer vmBuf, uint8 flags,
|
|
const RelFileLocator rlocator);
|
|
extern uint8 visibilitymap_get_status(Relation rel, BlockNumber heapBlk, Buffer *vmbuf);
|
|
extern void visibilitymap_count(Relation rel, BlockNumber *all_visible, BlockNumber *all_frozen);
|
|
extern BlockNumber visibilitymap_prepare_truncate(Relation rel,
|
|
BlockNumber nheapblocks);
|
|
extern BlockNumber visibilitymap_truncation_length(BlockNumber nheapblocks);
|
|
|
|
#endif /* VISIBILITYMAP_H */
|