On Tue, Apr 12, 2016 at 10:54 AM, Craig Ringer <cr...@2ndquadrant.com> wrote: > On 12 April 2016 at 08:36, Michael Paquier wrote: > The only way we really have at the moment is shared_preload_libraries.
That's exactly my point. > If you rely on shared_preload_libraries, then "oops, I forgot to put > myextension in shared_preload_libraries on the downstream" becomes a Bad > Thing. There's no way to go back and redo the work you've passed over. You > have to recreate the standby. Worse, it's silently wrong. The server has no > idea it was meant to do anything and no way to tell the user it couldn't do > what it was meant to do. Well, one playing with the generic WAL record facility is > We can't register redo routines in the catalogs because we don't have access > to the syscaches etc during redo (right?). Yes, the startup process does not have that knowledge. > So how do we look at a generic log record, say "ok, the upstream that wrote > this says it needs to invoke registered generic xlog hook 42, which is > <func> from <extension> at <ptr>" ? > > Personally I'd be willing to accept the limitations of the s_p_l and hook > approach to the point where I think we should add the hook and accept the > caveats of its use ... but I understand the problems with it. Honestly, so do I, and I could accept the use of a hook in generic_redo in this code path which is really... Generic. Any other infrastructure is going to be one brick shy of a load, and we are actually sure that those routines are getting loaded once we reach the first redo routine as far as I know. We could for example force the hook to set some validation flags that are then checked in the generic redo routine, and mark in the WAL record itself that this record should have used the hook. If the record is replayed and this hook is missing, then do a FATAL and prevent recovery to move on. -- Michael -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers