Index use during Hot Standby
От | Simon Riggs |
---|---|
Тема | Index use during Hot Standby |
Дата | |
Msg-id | 1224500863.3808.650.camel@ebony.2ndQuadrant обсуждение исходный текст |
Ответы |
Re: Index use during Hot Standby
|
Список | pgsql-hackers |
For Hot Standby I need to mark which indexes are usable or not. There are three aspects to index use during recovery: * Certain index types may not correctly implement fully concurrent locking order to allow that index type to be used during recovery. * Other indexes might become unusable as indexAM code determines particular indexes are corrupt. * Any index type that is not WAL logged will never be usable during recovery. I've looked into the first of those concerns and can't find any reason to believe index _redo code is dangerous for concurrent use. In particular, even though some actions are split across multiple WAL records does not imply that the individual parts of that action are not concurrent. Please could people double check that analysis? Assuming that is OK, the second and third concerns need to be addressed. Currently, the second concern is simply ignored. Should we continue that? We can handle the third concern in a couple of ways: 1. Implement WAL logging for hash indexes 2. Implement an extra flag on pg_am that would be checked when we build relcache so that all indexes of a certain type show as invalid during recovery. 3. Implement an extra indexAM API call that allows indexAM to decide when/if index is valid during recovery. This would also cover the second concern neatly in a single API call. I heard that people were working on (1). Are they going to make the deadline or not? If not, I will have to do some further work on this. I suggest that I wait until after deadline to implement (2) or (3), in case somebody fixes this up in the next few weeks. I'm also happy to help out a little with adding WAL to hash indexes. In general, every place that we do MarkBufferDirty() we need to make some WAL entries (probably). MarkBufferDirty is rarely called directly (once...), but the next level of code is called in these places: hash.c hashbulkdelete() hashovfl.c _hash_addovflpage() _hash_getovflpage _hash_freeovflpage -- looks complex _hash_initbitmap _hash_squeezebucket hashpage.c _hash_metapinit() _hash_splitbucket() _hash_expandtable() hashinsert.c _hash_doinsert() -- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
В списке pgsql-hackers по дате отправления: