Skip site navigation (1) Skip section navigation (2)

Additional options for Sync Replication

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Additional options for Sync Replication
Date: 2011-03-27 21:45:03
Message-ID: (view raw, whole thread or download thread mbox)
Lists: 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.


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

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         
 PostgreSQL Development, 24x7 Support, Training & Services

Attachment: syncrep_queues.v1.cpatch
Description: application/octet-stream (18.6 KB)


pgsql-hackers by date

Next:From: David FetterDate: 2011-03-27 22:05:59
Subject: Re: Can I check if somebody is superuser in stored procedure?
Previous:From: Martijn van OosterhoutDate: 2011-03-27 21:38:59
Subject: Re: Open issues for collations

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group