Re: Block level concurrency during recovery
От | Simon Riggs |
---|---|
Тема | Re: Block level concurrency during recovery |
Дата | |
Msg-id | 1224714044.27145.538.camel@ebony.2ndQuadrant обсуждение исходный текст |
Ответ на | Block level concurrency during recovery (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: Block level concurrency during recovery
|
Список | pgsql-hackers |
On Mon, 2008-10-20 at 13:54 +0100, Simon Riggs wrote: > I'm looking at how to make queries safe during recovery, in the presence > of concurrent changes to blocks. In particular, concurrent removal of > rows that might be read by queries. > > My thinking is > * we ignore LockRelationForExtension(). Normal queries never request it. > All new blocks were created with that lock held and we are replaying > changes serially, so we do not need to re-create that lock. We already > do this, so no change. > * re-create the Cleanup lock on blocks, when the original operation was > performed while a Cleanup lock was held. > > So the plan is to introduce a new XLogLockBufferForCleanup() function > and then use it in all places where a cleanup lock was held during the > write of the WAL record. > > This means we will need to hold cleanup lock: > > * while RM_HEAP2_ID records are applied (Freeze, Clean, CleanMove) > > * while an XLOG_BTREE_DELETE was generated by VACUUM - this record type > is not always generated by VACUUM. So split this WAL record into two > types XLOG_BTREE_DELETE and XLOG_BTREE_VACUUM, so we can hold Cleanup > lock while applyinh XLOG_BTREE_VACUUM. (This may not be required, but > I'd rather do the full locking now and relax it later). > > * Whenever we apply a backup block that performs the same function as > any of the above WAL records. So we would hold Cleanup lock when > applying WAL records of types > all RM_HEAP2_ID types > XLOG_BTREE_VACUUM > > I'm most of the way through implementing the above and will post patch > as a separate item to make it easier to inspect. Here's the code to implement this portion. I'm undecided as to whether this is too much code or too little. I'm somewhat uncertain as to the locking requirements for the physical scan during a vacuum. I've worked out various options if we need to change this. Also, the way I take a cleanup lock during RestoreBkpBlocks() seems very ugly, but too much additional code seems over the top also. I'm integrating into rest of patch now. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support
Вложения
В списке pgsql-hackers по дате отправления: