Additional options for Sync Replication - Mailing list pgsql-hackers

From Simon Riggs
Subject Additional options for Sync Replication
Date
Msg-id AANLkTinxoYmWoWBsJxmnpJHJh_YAN9vFmnmhNJDMev4M@mail.gmail.com
Whole thread Raw
Responses Re: Additional options for Sync Replication
Re: Additional options for Sync Replication
List pgsql-hackers
Proposed changes:  Make synchronous_replication into an enum, so we
can now also say synchronous_replication = recv, flush or apply as
well as on or off.
synchronous_replication = on is the same as "flush"

Benefit:  Allows 2 additional wait modes for sync rep: wait for
receive and wait for apply.

Rationale:

I was hoping to fine tune/tweak Sync Rep after feedback during beta,
but my understanding of current consensus is that that will be too
late to make user visible changes. So I'm proposing this change now,
before Beta, rather than during Beta.

Since we now have replies from standby arriving when we receive data,
not just fsync, we may as well do something useful with them in this
release.

So I reintroduce changes made in the original patch submission that
were split out for piece-by-piece commit. This was also part of the
originally agreed functionality for Sync Rep. So I don't expect any
procedural difficulties in accepting this patch. Heikki was right to
request removal of that code while we got things correct. Adding it
back now is much simpler.

The internal changes are minor, simply changing things so we have 3
queues rather than 1. The user backend path is identical in length,
the sync standby path very slightly longer. Replies from standby
continue to be sent every 100ms until all flushed WAL has been
applied, then it falls back to the wal_receiver_status_interval, again
a minor change.

The parameter is an enum since multiple people called Josh asked for a
very simple interface "on" or "off", while others requested multiple
favours. This gives us both.

I expect "recv" mode to be even more useful in next release, with
WALWriter active during recovery.

Patch feedback please.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Attachment

pgsql-hackers by date:

Previous
From: Martijn van Oosterhout
Date:
Subject: Re: Open issues for collations
Next
From: David Fetter
Date:
Subject: Re: Can I check if somebody is superuser in stored procedure?