On Thu, Feb 4, 2016 at 4:10 PM, Andres Freund <and...@anarazel.de> wrote: > On 2016-02-04 18:21:41 +0530, Amit Kapila wrote: >> I think generally it is good idea, but one thing worth a thought is that >> by doing so, we need to acquire all WAL Insertion locks every >> LOG_SNAPSHOT_INTERVAL_MS to check the last_insert_pos for >> every slot, do you think it is matter of concern in any way for write >> workloads or it won't effect as we need to do this periodically? > > Michael and I just had an in-person discussion, and one of the topics > was that. The plan was basically to adapt the patch to: > 1) Store the progress lsn inside the wal insert lock > 2) Change the HasActivity API to return an the last LSN at which there > was activity, instead of a boolean. > 3) Individually acquire each insert locks's lwlock to get it's progress > LSN, but not the exclusive insert lock. We need the lwllock to avoid > a torn 8byte read on some platforms.
4) Switch the condition to decide if a checkpoint should be skipped using the last activity position compared with ProcLastRecPtr in CreateCheckpoint to see if any activity has occurred since the checkpoint record was inserted, and do not care anymore if the previous record and current record are on different segments. This would basically work. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
