From: | Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> |
---|---|
To: | Dmitry Melekhov <dm(at)belkam(dot)com> |
Cc: | Glyn Astill <glynastill(at)yahoo(dot)co(dot)uk>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: please explain vacuum with WAL |
Date: | 2008-07-08 09:28:42 |
Message-ID: | 4873334A.30207@postnewspapers.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Dmitry Melekhov wrote:
> Glyn Astill пишет:
>> WAL is the journal for postgres, so every event that happens goes into the WAL. Using it for backup or replication simply uses it to replay all events on the backup / replicated database.
> As I thought, thank you.
> But why vacuum generates WAL ? As I understand all database changes are
> already logged....
Sure, but at a very low level. It's not logging statements and replaying
those statements; it's more of a block-level change log.
My understanding is that for later WAL records from the master server to
make sense to a slave that's replaying them, the changes made by VACUUM
must also be replicated. Otherwise the archived WAL segments from the
master will be asking the slave to do things that just don't make sense
given the slave's current understanding of the database state.
--
Craig Ringer
From | Date | Subject | |
---|---|---|---|
Next Message | Dennis Brakhane | 2008-07-08 10:32:17 | Re: Query running slow but was running fine before |
Previous Message | Dmitry Melekhov | 2008-07-08 09:22:35 | Re: please explain vacuum with WAL |