Re: Patch for fail-back without fresh backup

On Thu, Sep 19, 2013 at 4:02 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:

>
>
> Hmm... when synchronous_transfer is set to data_flush,
> IMO the intuitive behaviors are
>
> (1) synchronous_commit = on
> A data flush should wait for the corresponding WAL to be
> flushed in the standby
>
> (2) synchronous_commit = remote_write
> A data flush should wait for the corresponding WAL to be
> written to OS in the standby.
>
> (3) synchronous_commit = local
> (4) synchronous_commit = off
> A data flush should wait for the corresponding WAL to be
> written locally in the master.
>

I thought synchronous_commit and synchronous_transfer are kind of
orthogonal to each other. synchronous_commit only controls whether and how
to wait for the standby only when a transaction commits.
synchronous_transfer OTOH tells how to interpret the standby listed in
synchronous_standbys parameter. If set to "commit" then they are
synchronous standbys (like today). If set to "data_flush", they are
asynchronous failback safe standby and if set to "all" then they are
synchronous failback safe standbys. Well, its confusing :-(

So IMHO in the current state of things, the synchronous_transfer GUC can
not be changed at a session/transaction level since all backends, including
background workers must honor the settings to guarantee failback safety.
synchronous_commit still works the same way, but is ignored if
synchronous_transfer is set to "data_flush" because that effectively tells
us that the standbys listed under synchronous_standbys are really *async*
standbys with failback safety.

Thanks,
Pavan

--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee