On Thu, Apr 19, 2012 at 10:05 AM, Magnus Hagander <magnus@hagander.net> wrote:
> I admit to not having followed the discussion around the new mode for
> synchronous_commit very closely, so my apologies if this has been
> discussed and dismiseed - I blame failing to find it int he archives
> ;)
>
> My understanding from looking at the docs is that
> synchronous_commit=remote_write will always imply a *local* commit as
> well.
>
> Is there any way to set the system up to do a write to the remote,
> ensure it's in memory of the remote (remote_write mode, not full sync
> to disk), but *not* necessarily to the local disk? Meaning we're ok to
> release the transaction when the data is in memory both locally and
> remotely but not wait for I/O?
>
> Seems there is a pretty large usecase for this particular in our
> lovely new cloud environments with pathetic I/O performance....
Yeh, its on my TODO list.
What we need to do is to send the last written point as part of the
replication protocol, so the standby can receive it, yet know not to
apply it yet in case of crash.
I was expecting that to change as a result of efforts to improve
WALInsertLock, so I didn't want to do something that would be
immediately invalidated.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
