On Mon, Nov 27, 2006 at 04:35:30PM +0000, Simon Riggs wrote:
> On Mon, 2006-11-27 at 14:17 +0100, Florian G. Pflug wrote:
> > Devrim GUNDUZ wrote:
> > > Is there anything that may prevent two PostgreSQL servers to share the
> > > same pg_xlog directory; while one is using read-only and the other one
> > > is using the same partition for read and write? The problem is: If we
> > > share the same pg_xlog between production server and warm standby
> > > server; can you see any possibility of data/xlog corruption? Of course,
> > > warm standby server will mount that partition as read-only.
<snip>
> I suppose we might want to have multiple archivals occurring
> simultaneously by overlapping their start and stop times. That might be
> useful for situations where we have a bank of slow response tape
> drives/autoloaders?
>
> You'd need to have a second archive command to poll for completion.
> Currently archive_status has 2 states: .ready and .done. We could have 3
> states: .ready, .inprogress and .done. The first archive_command_start,
> if successful would move the state from .ready to .inprogress, while the
> second archive_command_confirm would move the state from .inprogress
> to .done. (Better names please...)
>
> With an asynchronous API, it would then be possible to fire off requests
> to archive lots of files, then return later to confirm their completion.
> Or in Devrim's case do nothing apart from wait for them to be applied by
> the Standby server.
>
> Anybody else see the need for this?
There might be a desire for async archiving in some circumstances, but I
don't really see what Devrim's after that couldn't just be done with our
current PITR. The only difference I can think of is not having to copy
logfiles around, but presumably that could be addressed by using
hardlinks instead of actually copying (at least on unix...) Maybe Devrim
has something else in mind?
--
Jim Nasby jim@nasby.net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)