Re: Clean shutdown and warm standby

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Andreas Pflug <pgadmin(at)pse-consulting(dot)de>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Guillaume Smet <guillaume(dot)smet(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Clean shutdown and warm standby
Date: 2009-04-28 05:30:08
Message-ID: 49F69460.4090706@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andreas Pflug wrote:
> Heikki Linnakangas wrote:
>>
>> 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.
>
> So to get this down to a solution, it appears to be correct to execute
> the RequestXLogSwitch right before CreateCheckPoint?

Hmm, then the checkpoint record isn't archived. That might be
acceptable, though, since all data would be safe in the preceding WAL.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message higepon 2009-04-28 05:33:54 Extra cost of "lossy mode" Bitmap Scan plan
Previous Message tomas 2009-04-28 04:49:38 Re: RFE: Transparent encryption on all fields