Re: Pluggable Indexes (was Re: rmgr hooks (v2))
От | Simon Riggs |
---|---|
Тема | Re: Pluggable Indexes (was Re: rmgr hooks (v2)) |
Дата | |
Msg-id | 1232636435.2327.874.camel@ebony.2ndQuadrant обсуждение исходный текст |
Ответ на | Re: Pluggable Indexes (was Re: rmgr hooks (v2)) (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Ответы |
Re: Pluggable Indexes (was Re: rmgr hooks (v2))
|
Список | pgsql-hackers |
On Thu, 2009-01-22 at 16:15 +0200, Heikki Linnakangas wrote: > Simon Riggs wrote: > > Immediate use cases for me would be > > > > * ability to filter WAL records based on database or relation > > This patch isn't enough to allow the catalog lookups. Without the > catalog lookups, you might as well implement that as an external tool, > like pglesslog. It makes it harder, but you can specify oids easily enough. Flat file handling reads pg_database during recovery, so can we. Or you can look in global/pg_database flat file. > > * ability to recover quickly from various types of bug, for example if > > new freespace code caused a corruption we would be able to sidestep it > > and get the database up again quickly without doing resetxlog and losing > > data. > > That might be useful. But again, could just as well be implemented as an > external tool like pglesslog. There is no WAL record for "no-op", at least not one of variable length. The WAL files can't just have chunks of zeroes in the middle of them, they must be CRC valid and chained together in the exact byte position. There isn't any way to do this, even if there were, that's a seriously complex way of doing that. pg_lesslog takes great care to reconstruct the files into the right shape because recovery is such an unforgiving mistress. > (the new FSM implementation isn't WAL-logged, so that particular > scenario isn't very plausible) Yeh, that was just a joke. But the principle applies to any index, as I'm sure you realise. -- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
В списке pgsql-hackers по дате отправления: