On Thu, Jan 9, 2014 at 09:36:47AM -0800, Jeff Janes wrote:
> Oh, right. Because the main reason for a sync replica degrading is that
> it's down. In which case it isn't going to record anything. This would
> still be useful for sync rep candidates, though, and I'll document why
> below. But first, lemme demolish the case for auto-degrade.
>
> So here's the case that we can't possibly solve for auto-degrade.
> Anyone who wants auto-degrade needs to come up with a solution for this
> case as a first requirement:
>
>
> It seems like the only deterministically useful thing to do is to send a NOTICE
> to the *client* that the commit has succeeded, but in degraded mode, so keep
> your receipts and have your lawyer's number handy. Whether anyone is willing
> to add code to the client to process that message is doubtful, as well as
> whether the client will even ever receive it if we are in the middle of a major
> disruption.
I don't think clients are the right place for notification. Clients
running on a single server could have fsync=off set by the admin or
lying drives and never know it. I can't imagine a client only wiling to
run if synchronous_standby_names is set.
The synchronous slave is something the administrator has set up and is
responsible for, so the administrator should be notified.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ Everyone has their own god. +