Andres Freund <and...@2ndquadrant.com> writes: > On 2014-07-07 09:57:20 -0400, Tom Lane wrote: >> Well, see the comment that explains why the logic is like this now:
> I think we should 'simply' make sequences assign a toplevel xid - then > we can get rid of that special case in RecordTransactionCommit(). And I > think the performance benefit of not having to wait on XLogFlush() for > readonly xacts due to hot prunes far outweighs the decrease due to the > xid assignment/commit record. I don't think that nextval()s are called > overly much without a later xid assigning statement. Yeah, that could well be true. I'm not sure if there are any other cases where we have non-xid-assigning operations that are considered part of what has to be flushed before reporting commit; if there are not, I'd be okay with changing nextval() this way. >> 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. > In the OP's case the session wasn't even started - so proper feedback > isn't that easy... Perhaps I'm wrong, but I think a WARNING emitted here would be seen in psql even though we're still in InitPostgres. If it isn't, we have a problem there anyhow, IMO. > We could special case that by forcing s_c=off until the session started > properly. Ugh. 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