Re: PATCH: add pg_current_xlog_flush_location function - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: PATCH: add pg_current_xlog_flush_location function
Date
Msg-id CAB7nPqQDzfot=5dhuQsX+9Nfo5PJnRhGxwsCRONeuf2tmFg4uA@mail.gmail.com
Whole thread Raw
In response to Re: PATCH: add pg_current_xlog_flush_location function  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: PATCH: add pg_current_xlog_flush_location function
List pgsql-hackers
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.
-- 
Michael



pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Speedup twophase transactions
Next
From: Michael Paquier
Date:
Subject: Re: Speedup twophase transactions