On Mon, 2008-09-15 at 10:04 -0400, Tom Lane wrote:
> Simon Riggs <simon@2ndQuadrant.com> writes:
> > The version mismatch idea presumes that a code author would structure
> > their code in two pieces: one to generate the WAL and one to read it.
>
> No, the version mismatch problem is that you might try to read the WAL
> with a different version of the plugin than you wrote it with. Or maybe
> with a completely unrelated plugin that was unfortunate enough to choose
> the same rmgr ID. We can't afford to insert complete versioning
> information into each WAL record, so it's going to be pretty difficult
> to avoid this risk.
I'm happy to include additional things into the patch, but I don't see
anything to force rejection of the patch entirely, from what has been
said.
Bottom line is that any backup of Postgres needs to include plugin
directories, otherwise parts of the application could stop working
following restore. This patch doesn't change that.
I proposed a registration scheme to avoid one of those problems.
If a plugin changed its file format, it would clearly need to include a
version test within it. It wouldn't be the fault of the plugin API if
the plugin author didn't handle that. But if they can work out how to
build an index AM and write WAL, I'm sure they can handle version
management between software components and informative error messages if
problems occur. And if they can't, they'll get a bad rep and nobody will
use the plugin.
Few ideas:
* add the rmgr bms to the long header of each WAL file
* change !RmgrIdIsValid() so that it causes FATAL by default. This then
allows people to correct a mistake and retry. We provide an option to
treat such errors as corrupt data and assume we have reached the end of
WAL.
-- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support