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
