]> granicus.if.org Git - postgresql/commit
Truncate pg_multixact/'s contents during crash recovery
authorAlvaro Herrera <alvherre@alvh.no-ip.org>
Fri, 29 Nov 2013 14:26:41 +0000 (11:26 -0300)
committerAlvaro Herrera <alvherre@alvh.no-ip.org>
Sat, 30 Nov 2013 00:47:15 +0000 (21:47 -0300)
commit1df0122daa6510eed4146033379a5055f66f5a8e
tree8784e3d301ca6cb27cf3dfc51e8285a4b1dde924
parentf54106f77e6d71cbb3fa0924095e5142341fde2b
Truncate pg_multixact/'s contents during crash recovery

Commit 9dc842f08 of 8.2 era prevented MultiXact truncation during crash
recovery, because there was no guarantee that enough state had been
setup, and because it wasn't deemed to be a good idea to remove data
during crash recovery anyway.  Since then, due to Hot-Standby, streaming
replication and PITR, the amount of time a cluster can spend doing crash
recovery has increased significantly, to the point that a cluster may
even never come out of it.  This has made not truncating the content of
pg_multixact/ not defensible anymore.

To fix, take care to setup enough state for multixact truncation before
crash recovery starts (easy since checkpoints contain the required
information), and move the current end-of-recovery actions to a new
TrimMultiXact() function, analogous to TrimCLOG().

At some later point, this should probably done similarly to the way
clog.c is doing it, which is to just WAL log truncations, but we can't
do that for the back branches.

Back-patch to 9.0.  8.4 also has the problem, but since there's no hot
standby there, it's much less pressing.  In 9.2 and earlier, this patch
is simpler than in newer branches, because multixact access during
recovery isn't required.  Add appropriate checks to make sure that's not
happening.

Andres Freund
src/backend/access/transam/multixact.c
src/backend/access/transam/xlog.c
src/include/access/multixact.h