On Fri, Nov 4, 2011 at 5:15 AM, Simon Riggs wrote:
> On Fri, Nov 4, 2011 at 2:36 AM, Fujii Masao wrote:
>> If we introduce "walrestore" process, pg_standby seems no longer useful.
>> We should get rid of it?
>
> Removing things too quickly can cause problems. There's no harm done
> by keeping it
On Fri, Nov 4, 2011 at 11:08 AM, Dimitri Fontaine
wrote:
> Fujii Masao writes:
>> If we introduce "walrestore" process, pg_standby seems no longer useful.
>
> pg_standby is one possible restore_command, right? I had understood
> that walrestore would be the process that cares for running that
>
Fujii Masao writes:
> If we introduce "walrestore" process, pg_standby seems no longer useful.
pg_standby is one possible restore_command, right? I had understood
that walrestore would be the process that cares for running that
command, not another implementation of it.
That said, I would reall
On Fri, Nov 4, 2011 at 2:36 AM, Fujii Masao wrote:
> If we introduce "walrestore" process, pg_standby seems no longer useful.
> We should get rid of it?
Removing things too quickly can cause problems. There's no harm done
by keeping it a while longer.
I agree it should go, just want to be absol
On Thu, Nov 3, 2011 at 2:52 AM, Simon Riggs wrote:
> On Wed, Nov 2, 2011 at 5:20 PM, Tom Lane wrote:
>> Dimitri Fontaine writes:
>>> The only part of your proposal that I don't like is the process name,
>>> that "deArchiver" thing. "wal restore process" or something like that
>>> would be bette
On Wed, Nov 2, 2011 at 5:20 PM, Tom Lane wrote:
> Dimitri Fontaine writes:
>> The only part of your proposal that I don't like is the process name,
>> that "deArchiver" thing. "wal restore process" or something like that
>> would be better. We already have "wal writer process" and "wal sender
>
Dimitri Fontaine writes:
> The only part of your proposal that I don't like is the process name,
> that "deArchiver" thing. "wal restore process" or something like that
> would be better. We already have "wal writer process" and "wal sender
> process" and "wal receiver process".
+1, "restore" s
On Wed, Nov 2, 2011 at 12:42 PM, Simon Riggs wrote:
> Any standby can now become a sender node, so the meaning in that case
> would be the same. That takes a little time to get your head around,
> and I'm not used to it myself yet.
I think a new parameter will be more clear, even if in practice t
On Wed, Nov 2, 2011 at 4:14 PM, Robert Haas wrote:
> On Wed, Nov 2, 2011 at 11:56 AM, Simon Riggs wrote:
>> My solution is to create a new process called the DeArchiver. This
>> will run restore_command in a tight loop until the number of files
>> would exceed wal_keep_files, then sleep. Each tim
Simon Riggs writes:
> My solution is to create a new process called the DeArchiver. This
> will run restore_command in a tight loop until the number of files
> would exceed wal_keep_files, then sleep. Each time the DeArchiver
> executes restore_command it will set the return code and if rc=0 the
>
On Wed, Nov 2, 2011 at 11:56 AM, Simon Riggs wrote:
> My solution is to create a new process called the DeArchiver. This
> will run restore_command in a tight loop until the number of files
> would exceed wal_keep_files, then sleep. Each time the DeArchiver
> executes restore_command it will set t
Currently, the Startup process is responsible for running
restore_command. So when the Startup process is busy or waiting, then
no new WAL files arrive.
That has these effects
* Recovery must wait while the Startup process requests next WAL file.
This reduces performance of archive recovery.
* If
12 matches
Mail list logo
