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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
