On 2014-07-07 12:06:14 -0400, Tom Lane wrote: > 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'm not aware of any adhoc, but I think to actually change it someone would have to iterate over all wal record types to make sure. > >> 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. Yes, it is visible. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers