Andres Freund <and...@2ndquadrant.com> writes: > I think we should rework RecordTransactionCommit() to only wait for the > standby if `markXidCommitted' and not if `wrote_xlog'. There really > isn't a reason to make a readonly transaction's commit wait just because > it did some hot pruning.
Well, see the comment that explains why the logic is like this now: * If we didn't create XLOG entries, we're done here; otherwise we * should flush those entries the same as a commit record. (An * example of a possible record that wouldn't cause an XID to be * assigned is a sequence advance record due to nextval() --- we want * to flush that to disk before reporting commit.) I agree that HOT pruning isn't a reason to make a commit wait, but nextval() is. We could perhaps add more flags that would keep track of which sorts of xlog entries justify a wait at commit, but TBH I'm skeptical of the entire proposition. Having synchronous replication on with no live slave *will* result in arbitrary hangs, and the argument that this particular case should be exempt seems a bit thin to me. The sooner the user realizes he's got a problem, the better. If read-only transactions don't show a problem, the user might not realize he's got one until he starts to wonder why autovac/autoanalyze aren't working. I think a more useful line of thought would be to see if we can't complain more loudly when we have no synchronous standby. Perhaps a "WARNING: waiting forever for lack of a synchronous standby" could be emitted when a transaction starts to wait. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers