From: "Tom Lane" <tgl@sss.pgh.pa.us>
> Andres Freund <andres@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.
Thank you all for letting me know your thoughts. I understood and agree
that read-only transactions, including the connection establishment one,
should not wait for the standby nor the XLOG flush at commit, and the
current documentation/specification should not be changed.
I'll consider how to fix this problem, learning the code, then I'll ask for
review. I'd like to submit the patch for next CF if possible.
From: "Fujii Masao" <masao.fujii@gmail.com>
> Sounds good direction. One question is: Can RecordTransactionCommit()
> avoid
> waiting for not only replication but also local WAL flush safely in
> such read-only
> transaction case?
I'd appreciate any opinion on this, too.
Regards
MauMau