Fujii Masao wrote:
Hi,

On Mon, Apr 27, 2009 at 8:43 PM, Heikki Linnakangas
<heikki.linnakan...@enterprisedb.com> wrote:
Fujii Masao wrote:
On Fri, Apr 24, 2009 at 3:20 PM, Heikki Linnakangas
<heikki.linnakan...@enterprisedb.com> wrote:
It's not safe to write WAL after the checkpoint, as RequestXLogSwitch()
does. After restart, the system will start inserting WAL from the
checkpoint
redo point, which is just before the XLOG_SWITCH record, and will
overwrite
it.
Since, in this case, the WAL file including XLOG_SWITCH exists
in archive, I don't think that it's unsafe, i.e. XLOG_SWITCH would
be treated as the last applied record and not be overwritten. WAL
records would start to be inserted from the subsequent file (with
new timeline).
It will be overwritten in a normal non-archive-recovery startup.

Hmm, you mean the case where the system crashes after
inserting XLOG_SWITCH and before archiving the WAL file
containing it?

No, no crash is involved. Just a normal server shutdown and start:

1. Server shutdown is initiated
2. A shutdown checkpoint is recorded at XLOG point 1234, redo ptr is also 1234. 3. A XLOG_SWITCH record is written at 1235, right after the checkpoint record. 4. The last round of archiving is done. The partial WAL file containing the checkpoint and XLOG_SWITCH record is archived.
5. Postmaster exits.

6. Postmaster is started again. Since the system was shut down cleanly, no WAL recovery is done. The WAL insert pointer is initialized to right after the redo pointer, location 1235, which is also the location of the XLOG_SWITCH record. 7. The next WAL record written will be written at 1235, overwriting the XLOG_SWITCH record. 8. When the WAL file fills up, the system will try to archive the same WAL file again, this time with additional WAL records that after the checkpoint record.

--
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to