On Thu, 2011-07-28 at 16:20 -0400, Robert Haas wrote:
> On Thu, Jul 28, 2011 at 3:40 PM, Hannu Krosing <hannu@2ndquadrant.com> wrote:
> > On Thu, 2011-07-28 at 21:32 +0200, Hannu Krosing wrote:
> >> On Thu, 2011-07-28 at 14:27 -0400, Robert Haas wrote:
> >>
> >> > Hmm, interesting idea. However, consider the scenario where some
> >> > transactions are using synchronous_commit or synchronous replication,
> >> > and others are not. If a transaction that needs to wait (either just
> >> > for WAL flush, or for WAL flush and synchronous replication) inserts
> >> > its commit record, and then another transaction with
> >> > synchronous_commit=off comes along and inserts its commit record, the
> >> > second transaction will have to block until the first transaction is
> >> > done waiting.
> >>
> >> What is the current behavior when the synchronous replication fails (say
> >> the slave breaks down) - will the transaction be rolled back at some
> >> point or will it wait indefinitely , that is until a new slave is
> >> installed ?
> >
> > More importantly, if the master crashes after the commit is written to
> > WAL, will the transaction be rolled back after recovery based on the
> > fact that no confirmation from synchronous slave is received ?
>
> No. You can't roll back a transaction once it's committed - ever.
so in case of stuck slave the syncrep transcation is committed after
crash, but is not committed before the crash happens ?
ow will the replay process get stuc gaian during recovery ?
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
