Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Running PostgreSQL 9.0.1, with streaming replication keeping one read-only mirror instance up to date. Auto-vaccuum is on on the primary, except for a few tables which are not vacuumed by the auto-vacuum daemon, in an effort to reduce business-hour IO. These tables are "materialised views".

Each night at midnight, we run a vacuum across the database in order to clean up those tables that are excluded from the auto-vacuum. I'm wondering if that process replicates across to the mirror, or if I need to set up vacuum on the mirror as well?

share|improve this question
Excellent question. The streaming replication uses the Write-Ahead Log, so it boils down to whether the changes VACUUM makes are logged or not. – DerfK Dec 13 '10 at 22:55
Interestingly, I have auto-vacuum turned ON on the read-only mirror, but looking in the table stats it doesn't appear have ever run; as all tables list 0 live/dead tuples, and there are no histories visible of vacuums or analyzes. – Scott Herbert Dec 14 '10 at 0:23 - 25.5.2. Handling query conflicts - "Application of a vacuum cleanup record from WAL conflicts with standby transactions whose snapshots can still "see" any of the rows to be removed............. This seems to suggest that VACUUM is WAL logged, and therefore it's a "yes" to my question. Would love to get some more info from a PG guru though! – Scott Herbert Dec 14 '10 at 0:40
The data from dynamic views is expected to be different on primary vs. the standby. These views use system functions to gather the data, and those functions read the data from in-memory data structures rather than from a physical table. For eg., performing an ANALYZE on primary will update the optimizer statistics (used for query planning) on the standby too, but the time the ANALYZE was performed on the table won’t reflect in the pg_stat_user_tables since that information is not logged in transaction logs. – Gurjeet Singh Oct 1 '13 at 22:07
So the conclusion is that AUTOVACUUM occuring on the master has no effect on it running on the slave, correct? Assuming this is the case, if I have a table that has NO updates/deletes, just inserts, would it be feasible to disable autovacuum in the master, since I'm just writing to it, and the reads happen on the slave. – Henley Chiu Oct 4 '13 at 18:58
up vote 5 down vote accepted

Vacuum and autovacuum replicate like any other write operation. (Well, they are obviously somewhat special internally, but as far as your question is concerned, they are normal write operations.) Running vacuum or autovacuum on the slave doesn't do anything and is not necessary.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.