On 2014-01-16 09:25:51 -0800, Jeff Janes wrote: > On Thu, Nov 21, 2013 at 2:43 PM, Andres Freund <and...@2ndquadrant.com>wrote: > > > On 2013-11-21 14:40:36 -0800, Jeff Janes wrote: > > > But if the transaction would not have otherwise generated WAL (i.e. a > > > select that did not have to do any HOT pruning, or an update with zero > > rows > > > matching the where condition), doesn't it now have to flush and wait when > > > it would otherwise not? > > > > We short circuit that if there's no xid assigned. Check > > RecordTransactionCommit(). > > > > It looks like that only short-circuits the flush if both there is no xid > assigned, and !wrote_xlog. (line 1054 of xact.c)
Hm. Indeed. Why don't we just always use the async commit behaviour for that? I don't really see any significant dangers from doing so? It's also rather odd to use the sync rep mechanisms in such scenarios... The if() really should test markXidCommitted instead of wrote_xlog. > I do see stalls on fdatasync on flush from select statements which had no > xid, but did generate xlog due to HOT pruning, I don't see why WAL logging > hint bits would be different. Are the stalls at commit or while the select is running? If wal_buffers is filled too fast, which can easily happen if loads of pages are hinted and wal logged, that will happen independently from RecordTransactionCommit(). Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers