On Mon, 2008-09-15 at 10:04 -0400, Tom Lane wrote: > Simon Riggs <[EMAIL PROTECTED]> 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.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers