Re: Some other things about contrib/bloom and generic_xlog.c - Mailing list pgsql-hackers

From Craig Ringer
Subject Re: Some other things about contrib/bloom and generic_xlog.c
Date
Msg-id CAMsr+YHBJbWGkbJAaYZvEBqyt0QYgZhbKwRwx4ZHkm7jQuTLgg@mail.gmail.com
Whole thread Raw
In response to Re: Some other things about contrib/bloom and generic_xlog.c  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Some other things about contrib/bloom and generic_xlog.c  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 12 April 2016 at 20:48, Robert Haas <robertmhaas@gmail.com> wrote:
 
> 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>" ?

Record enough information in WAL that the rmgrs can have names instead
of ID numbers.  Stick the list of extension rmgrs in use into each
checkpoint record and call it good.

Repeating the mapping at each checkpoint sounds pretty reasonable and means we always know what we need. There's no need to bloat each record with an extension name and no need for any kind of ugly global registration. The mapping table would be small and simple. I like it.

Of course, it's all maybe-in-future stuff at this point, but I think that's a really good way to approach it.

There's no way around the fact that user defined redo functions can affect reliability. But then, so can user-defined data types, functions, bgworkers, plpython functions loading ctypes, plpython functions getting creative in the datadir, and admins who paste into the wrong window. The scope for problems is somewhat greater but not IMO prohibitively so.

--
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

pgsql-hackers by date:

Previous
From: Alexander Korotkov
Date:
Subject: Re: Some other things about contrib/bloom and generic_xlog.c
Next
From: Tom Lane
Date:
Subject: Re: Preprocessor condition fix