Coding TODO for 8.4: Synch Rep - Mailing list pgsql-hackers

Hi,

I'd like to clarify the coding TODO of Synch Rep for 8.4. If indispensable
TODO item is not listed, please feel free to let me know.

1. replication_timeout_action (GUC)

This is new GUC to specify the reaction to replication_timeout. In the
latest patch, the user cannot configure the reaction, and the primary
always continue processing after the timeout occurs. In the next, the
user can choose the reaction:

- standalone When the backend waits for replication much longer than the specified time (replication_timeout), that is,
thetimeout occurs, the backend sends replication_timeout interrupt to walsender. Then, walsender closes the connection
tothe standby, wake all waiting backends and exits. All the processing go on the standalone primary.
 

- down When the timeout occurs, walsender signals SIGQUIT to postmaster instead of waking all backends, then the
primaryshuts down immediately.
 


2. log_min_duration_replication (GUC)

If the backend waits much longer than log_min_duration_replication,
the warning log message is produced like log_min_duration_xxx.
Unit is not percent against the timeout but msec because "msec" is
more convenient.


3. recovery.conf

I need  to change the recovery.conf patch to work with EXEC_BACKEND.
Someone advised locally me to move the options of replication to
postgresql.conf for convenient. That is, in order to start replication,
all the configuration files the user has to care is postgresql.conf.
Which do you think is best?

The options which I'm going to use for replication are the following.

- host of the primary (new)
- port of the primary (new)
- username to connect to the primary (new)
- restore_command


4. sleeping
http://archives.postgresql.org/pgsql-hackers/2008-12/msg00438.php

I'm looking for the better idea. How should we resolve that problem?
Only reduce the timeout of pq_wait to 100ms? Get rid of
SA_RESTART only during pq_wait as follows?
  remove SA_RESTART  pq_wait()  add SA_RESTART


5. Extend archive_mode
http://archives.postgresql.org/pgsql-hackers/2008-12/msg00718.php


6. Continuous recovery without pg_standby
http://archives.postgresql.org/pgsql-hackers/2008-12/msg00296.php


7. Switch modes on the standby
http://archives.postgresql.org/pgsql-hackers/2008-12/msg00503.php


8. Define new trigger to promote the standby

In the latest patch, since the standby always recover with pg_standby,
the standby is promoted by only the trigger file of pg_standby. But, the
architecture should be changed as indicated #6, 7. We need to define
new trigger to promote the standby to the primary. I have two ideas:

- Trigger based on file Like pg_standby, startup process also check whether the trigger file exists periodically. The
pathof trigger file is specified in recovery.conf. The advantage of this idea is that one trigger file can promote the
standbyeasily whether it's in FLS or SLS mode.
 

- Trigger based on signal If postmaster received SIGTERM during recovery, the standby stops walreceiver, completes
recoveryand becomes the primary. In current HEAD, SIGTERM (Smart Shutdown) during recovery is not used yet.
 

Which idea is better? Or, do you have any other better idea?

In my design, trigger is always required to promote the standby. I mean,
the standby is not permitted to complete recovery and become the
primary without trigger. Even if the standby finds the corruption of WAL
record, it waits for trigger before ending recovery. This is because
postgres cannot make a correct decision whether to end recovery,
and wrong decision might cause split brain and undesirable increment
of timeline. Is this design OK?


9. New synchronous option on the standby
http://archives.postgresql.org/pgsql-hackers/2008-12/msg01160.php


Pending now. These features are indispensable for 8.4?

10. Hang all connections everything is setup for "sync rep"
http://archives.postgresql.org/pgsql-hackers/2008-12/msg00868.php


Since there are many TODO items, I'm worried about the deadline.
When is the deadline of this commit fest? December 31st? first half
of January? ...etc?

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center