On Mon, Feb 29, 2016 at 10:30 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
> On 2/19/16 3:09 PM, Tom Lane wrote:
>> I see no need for an additional mechanism. Just watch pg_control until
>> you see DB_IN_PRODUCTION state there, then switch over to the same
>> connection probing that "pg_ctl start -w" uses.
>
> Here is a patch set around that idea.
>
> The subsequent discussion mentioned that there might still be a window
> between end of waiting and when read-write queries would be accepted. I
> don't know how big that window would be in practice and would be
> interested in some testing and feedback.
Here is some input for 0001 (useful taken independently):
+$node_primary->append_conf(
+ "postgresql.conf", qq(
+wal_level = hot_standby
+max_wal_senders = 2
+wal_keep_segments = 20
+hot_standby = on
+)
+ );
That's more or less allows_streaming => 1 in $node_primary->init.
+$node_standby->append_conf(
+ "recovery.conf", qq(
+primary_conninfo='$connstr_primary'
+standby_mode=on
+recovery_target_timeline='latest'
+)
+ );
Here you could just use enable_streaming => 1 when calling init_from_backup.
+$node_standby->command_like(['psql', '-X', '-A', '-t', '-c', 'SELECT
pg_is_in_recovery()'],
$node_standby->psql instead of a direct command? The result is
returned directly with the call to the routine.
+$node_standby->command_like(['psql', '-X', '-A', '-t', '-c', 'SELECT
pg_is_in_recovery()'],
+ qr/^f$/,
+ 'promoted standby is not in recovery');
Once again $node_standby->psql?
+sleep 3; # needs a moment to react
+
+$node_standby->command_like(['psql', '-X', '-A', '-t', '-c', 'SELECT
pg_is_in_recovery()'],
+ qr/^f$/,
+ 'promoted standby is not in recovery');
sleep() is something we should try to avoid as much as possible in our
tests. On slow platforms, take hamster, promote is surely going to
take longer than that to be processed by the standby node and put it
out of recovery. I would suggest using
$node_standby->poll_query_until('SELECT pg_is_in_recovery()') to
validate the end of the test.
--
Michael