From: "Tom Lane" <t...@sss.pgh.pa.us>
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.
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.fu...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
