On Wed, Sep 07, 2022 at 03:57:29AM -0500, Justin Pryzby wrote: > But that's also what'll happen when attempting to replay WAL using a postgres > build which doesn't support the necessary compression method. I ran into this > while compiling postgres locally while reporting the recovery_prefetch bug, > when I failed to compile --with-zstd.
Well, I am aware of that as that's how I have tested my change. I think that the case you are mentioning is really different than this change, though. The case you are mentioning gets triggered with the server-side compression of pg_basebackup with a client application, while the case of a block image restored can only happen when using inconsistent build options between a primary and a standby (at least in core, for the code paths touched by this patch). Before posting my previous patch, I have considered a few options: - Extend errormsg_buf with an error code, but the frontend does not care about that. - Make RestoreBlockImage() a backend-only routine and provide a better error control without filling in errormsg_buf, but I'd like to believe that this code is useful for some frontend code even if core does not use it yet in a frontend context. - Change the signature of RestoreBlockImage() to return an enum with at least a tri state instead of a boolean. For this one I could not convince myself that this is worth the complexity, as we are talking about inconsistent build options between nodes doing physical replication, and the error message is the useful piece to know what's happening (frontends are only going to consume the error message anyway). -- Michael
signature.asc
Description: PGP signature
