public inbox for [email protected]
help / color / mirror / Atom feedFrom: Heikki Linnakangas <[email protected]>
To: Simon Riggs <[email protected]>
Cc: Fujii Masao <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Subject: Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL
Date: Thu, 11 Feb 2010 15:28:51 +0200
Message-ID: <[email protected]> (raw)
In-Reply-To: <1265893599.7341.1454.camel@ebony>
References: <[email protected]>
<[email protected]>
<[email protected]>
<1265884657.7341.1192.camel@ebony>
<[email protected]>
<1265891248.7341.1346.camel@ebony>
<[email protected]>
<1265893599.7341.1454.camel@ebony>
Simon Riggs wrote:
> If you were running pg_standby as the restore_command then this error
> wouldn't happen. So you need to explain why running pg_standby cannot
> solve your problem and why we must fix it by replicating code that has
> previously existed elsewhere.
pg_standby cannot be used with streaming replication.
I guess you're next question is: why not?
The startup process alternates between streaming, and restoring files
from archive using restore_command. It will progress using streaming as
long as it can, but if the connection is lost, it will try to poll the
archive until the connection is established again. The startup process
expects the restore_command to try to restore the file and fail if it's
not found. If the restore_command goes into sleep, waiting for the file
to arrive, that will defeat the retry logic in the server because the
startup process won't get control again to retry establishing the
connection.
That's the the essence of my proposal here:
http://archives.postgresql.org/message-id/[email protected]
which is what has now been implemented.
To suppport a restore_command that does the sleeping itself, like
pg_standby, would require a major rearchitecting of the retry logic. And
I don't see why that'd desirable anyway. It's easier for the admin to
set up using simple commands like 'cp' or 'scp', than require him/her to
write scripts that handle the sleeping and retry logic.
The real problem we have right now is missing documentation. It's
starting to hurt us more and more every day, as more people start to
test this. As shown by this thread and some other recent posts.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
view thread (77+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
Subject: Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox