On Tue, Jan 12, 2016 at 6:35 AM, Simon Riggs wrote:
> Comments in xlog.c say
> "In addition to the shared variable, each backend has a private copy of
> LogwrtResult, which is updated when convenient."
> It is therefore valid to update the value of both Write and Flush positions
> at the same time, any time either is required.

Yes I saw this one yesterday when looking at this code. My comment
regarded the potential interactions between this field with XLogFlush,
but now I see that my concerns are not valid, updating more frequently
LogwrtResult may save some cycles though.

> My suggested commit pattern for this is...
> 1. Update existing function to maintain LogwrtResult more eagerly (separate
> patch)

The only place I see now that would benefit a bit from that is
UpdateMinRecoveryPoint when info_lck is taken, which can be called by
XLogFlush. Though I would expect this to have minimal impact.

> 2. Have the patch use the existing function name (main patch)

Yeah, we had better just use GetFlushRecPtr and be done with it. It
seems that there is little point to add a new function, and it is not
going to be called that much so its effects in updating LogwrtResult
would be minimized for a single backend.

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to