]> granicus.if.org Git - postgresql/commit
Have multixact be truncated by checkpoint, not vacuum
authorAlvaro Herrera <alvherre@alvh.no-ip.org>
Fri, 27 Jun 2014 18:43:53 +0000 (14:43 -0400)
committerAlvaro Herrera <alvherre@alvh.no-ip.org>
Fri, 27 Jun 2014 18:43:53 +0000 (14:43 -0400)
commitf741300c90141ee274f19a13629ae03a9806b598
tree3fbe8ea3f5bfc8426a7b7c09baefd9460ce0a07d
parentb7e51d9c06e6a0da50abbbd0603ecb80f0b6f02b
Have multixact be truncated by checkpoint, not vacuum

Instead of truncating pg_multixact at vacuum time, do it only at
checkpoint time.  The reason for doing it this way is twofold: first, we
want it to delete only segments that we're certain will not be required
if there's a crash immediately after the removal; and second, we want to
do it relatively often so that older files are not left behind if
there's an untimely crash.

Per my proposal in
http://www.postgresql.org/message-id/20140626044519.GJ7340@eldon.alvh.no-ip.org
we now execute the truncation in the checkpointer process rather than as
part of vacuum.  Vacuum is in only charge of maintaining in shared
memory the value to which it's possible to truncate the files; that
value is stored as part of checkpoints also, and so upon recovery we can
reuse the same value to re-execute truncate and reset the
oldest-value-still-safe-to-use to one known to remain after truncation.

Per bug reported by Jeff Janes in the course of his tests involving
bug #8673.

While at it, update some comments that hadn't been updated since
multixacts were changed.

Backpatch to 9.3, where persistency of pg_multixact files was
introduced by commit 0ac5ad5134f2.
src/backend/access/transam/multixact.c
src/backend/access/transam/xlog.c
src/backend/commands/vacuum.c
src/include/access/multixact.h