Fujii Masao <masao.fu...@gmail.com> writes: > On Tue, Jul 7, 2009 at 12:16 AM, Tom Lane<t...@sss.pgh.pa.us> wrote: >> I confess to not having paid much attention to this thread so far, but ... >> what is the rationale for having such a capability at all?
> If the XLOG files which are required for recovery exist only in the > primary server, > the standby server has to read them in some way. For example, when the latest > XLOG file of the primary server is 09 and the standby server has only 01, the > missing files (02-08) has to be read for recovery by the standby server. In > this > case, the XLOG records in 09 or later are shipped to the standby server in > real > time by synchronous replication feature. > The problem which I'd like to solve is how to make the standby server read the > XLOG files (XLOG file, backup history file and timeline history) which > exist only > in the primary server. In the previous patch, we had to manually copy those > missing files to the archive of the standby server or use the warm-standby > mechanism. This would decrease the usability of synchronous replication. So, > I proposed one of the solutions which makes the standby server read those > missing files automatically: introducing new function pg_read_xlogfile() which > reads the specified XLOG file. > Is this solution in the right direction? Do you have another > reasonable solution? This design seems totally wrong to me. It's confusing the master's pg_xlog directory with the archive. We should *not* use pg_xlog as a long-term archive area; that's terrible from both a performance and a reliability perspective. Performance because pg_xlog has to be fairly high-speed storage, which conflicts with it needing to hold a lot of stuff; and reliability because the entire point of all this is to survive a master server crash, and you're probably not going to have its pg_xlog anymore after that. If slaves need to be able to get at past WAL, they should be getting it from a separate archive server that is independent of the master DB. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers