From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Index use during Hot Standby |
Date: | 2008-10-20 11:07:43 |
Message-ID: | 1224500863.3808.650.camel@ebony.2ndQuadrant |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.com
PostgreSQL Training, Services and Support
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2008-10-20 12:43:50 | Re: contrib/pg_stat_statements |
Previous Message | ITAGAKI Takahiro | 2008-10-20 10:01:32 | Re: contrib/pg_stat_statements |