Simon Riggs <si...@2ndquadrant.com> writes: > So far, I have added the point that if a user requests a level of > confirmation that is currently unavailable, then it will use the highest > level of confirmation available now. That stops us from waiting for > timeout for every transaction we run if standby goes down hard, which > just freezes the application for long periods to no real benefit. It > also prevents applications from requesting durability levels the cluster > cannot satisfy, in the opinion of the sysadmin, since the sysadmin > specifies the max level on each standby.
That sounds like the commit-or-rollback when slave are gone question. I think this behavior should be user-setable, again per-transaction. I agree with you that the general case looks like your proposed default, but we already know that some will need "don't ack if not replied before the timeout", and they even will go as far as asking for it to be reported as a serialisation error of some sort, I guess… Regards, -- Dimitri Fontaine PostgreSQL DBA, Architecte -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
