Hello,
On Fri, Dec 5, 2008 at 12:09 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
>> I was expecting you to have walreceiver and startup share an end of WAL
>> address via shared memory, so that startup never tries to read past end.
>> That way we would be able to begin reading a WAL file *before* it was
>> filled. Waiting until a file fills means we still have to have
>> archive_timeout set to ensure we switch regularly.
>
> You mean that not pg_standby but startup process waits for the next
> WAL available? If so, I agree with you in the future. That is, I just think
> that this is next TODO because there are many problems which we
> should resolve carefully to achieve it. But, if it's essential for 8.4, I will
> tackle it. What is your opinion? I'd like to clear up the goal for 8.4.
Umm.. on second thought, this feature (continuous recovery without
pg_standby) seems to be essential for 8.4. So, I will try it.
Development plan:
- Share the end of WAL address via shared memory <--- Done!
- Change ReadRecord() to wait for the next WAL *record* available.
- Change ReadRecord() to restore the WAL from archive by using pg_standby before reaching the replication starting
position,then read the half-streaming WAL from pg_xlog.
- Add new trigger for promoting the standby to the primary. As the trigger, when fast shudown (SIGINT) is requested
duringrecovery, the standby would recover the WAL up to end and become the primary.
What system call does walreceiver have to call against the WAL
before startup process reads it? Probably we need to call write(2),
and don't need fsync(2) in Linux. How about other platform?
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center