On Thu, Feb 4, 2016 at 6:40 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. > 2) 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. > > I think that mostly should address your concerns? >
Yes, this sounds better and in-anycase we can do some benchmarks to verify the same once patch is in shape. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com