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) 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. Cheers, Jeff
