On Fri, Sep 23, 2011 at 11:43 AM, Aidan Van Dyk <ai...@highrise.ca> wrote:
> On Fri, Sep 23, 2011 at 4:41 AM, Heikki Linnakangas
> <heikki.linnakan...@enterprisedb.com> wrote:
>
>>> Unfortunately, it's impossible, because the error message "Could not read
>>> from file "pg_clog/0001" at offset 32768: Success" is shown (and startup
>>> aborted) before the turn for "redo starts at" message arrives.
>>
>> It looks to me that pg_clog/0001 exists, but it shorter than recovery
>> expects. Which shouldn't happen, of course, because the start-backup
>> checkpoint should flush all the clog that's needed by recovery to disk
>> before the backup procedure begins to them.
>
> I think the point here is that recover *never starts*. Something in
> the standby startup is looking for a value in a clog block that
> recovery hadn't had a chance to replay (produce) yet.
Ah. I think you are right - Heikki made the same point. Maybe some
of the stuff that happens just after this comment:
/*
* Initialize for Hot Standby, if enabled. We won't let backends in
* yet, not until we've reached the min recovery point specified in
* control file and we've established a recovery snapshot from a
* running-xacts WAL record.
*/
...actually needs to be postponed until after we've reached consistency?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
