Re: Core team statement on replication in PostgreSQL

On Thu, May 29, 2008 at 12:19 PM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
> That's not what Tom's email said, AIUI. "Synchronous" replication surely
> means that the master and slave always have the same set of transactions
> applied. Streaming <> synchronous. But streaming log shipping will allow us
> to get get closer to synchronicity in some situations, i.e. the window for
> missing transactions will be much smaller.
>
> Some of us were discussing this late on Friday night after PGcon. ISTM that
> we can have either 1) fairly hot failover slaves that are guaranteed to be
> almost up to date, or 2) slaves that can support read-only transactions but
> might get somewhat out of date if they run long transactions. The big
> problem is in having slaves which are both highly up to date and support
> arbitrary read-only transactions. Maybe in the first instance, at least, we
> need to make slaves choose which role they will play.

I personally would be thrilled to have slaves be query-able in any
fashion, even if 'wrong' under certain circumstances. Any
asynchronous solution by definition gives the wrong answer on the
slave. Read only slave is the #1 most anticipated feature in the
circles I run with. It would literally transform how the database
world thinks about postgres overnight. This, coupled with easier
standby setup (a pg_archive to mirror pg_restore) would be most
welcome!

merlin