Re: Proposed Resource Manager Changes

I would like to make a simple change to Resource Manager code to
introduce a plugin that can redefine or extend Rmgrs.

Providing an rmgr plugin in this way will also allow:

* filtering/control over apply of certain WAL records. We might decide
to skip all but certain tables, indexes, tablespaces or databases,
allowing a partial rebuild facility during PITR.

* ability to build a WAL debug utility that can stop/start/inspect WAL
records as we move thru WAL during recovery, or selectively output
specific record types or debug messages every N records. Would allow a
WAL debugger client GUI to be built into pgadmin, for example.

* dynamic addition of new index types, since we will be able to snap-in
any new index types via plugins, then insert into pg_am.

* additional actions alongside existing recovery actions. For example,
pre-processing of directories for new tablespace creation.

* new WAL records to allow issuing processing instructions to the
standby server with user defined meaning: "activate enterprise device
#72", "coordinate with user software x", "send SNMP trap 1157, to allow
us to measure delay between when it was sent on primary and when it was
processed on standby".

We could do each of the above in different ways, though it seems most
straightforward to provide a plugin that allows both extension and
redefinition of the RmgrTable.

Proposed way recognises that there is room for up to 255 rmgrs, since
the RmgrId is a single byte field on the WAL record.

* redefine RmgrTable as fixed size array of 255 elements that is
malloc'd into Startup process at beginning of StartupXlog()
* first few entries are "fixed" and we reserve first 32 elements for
future use by Postgres Core.
* values 33-127 are available by centrally managed registration to help
avoid conflicts in Postgres projects on pgfoundry
* values 128+ are user defined
* startup sets up fixed rmgrs, then calls plugin if it exists to modify
and/or add new rmgrs
* a new option to define behaviour if we receive an unhandled rmgrid.
Current behaviour is to declare this an invalid WAL record
* we might also check rmgrids when we enter XLogInsert() to ensure
everything written can be read if we crash, not sure whether people will
think that is overkill or essential (I'd say essential, but people may
fear performance problems).

Sample plugin showing filtering of WAL records for a specific databaseid
would be provided with patch.

(and yes, I see it will fall to me to document all of these new possible
types of plugin, so we have a new chapter on Server Extensibility).

Your thoughts?

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support

Simon Riggs <simon(at)2ndQuadrant(dot)com> wrote:

> I would like to make a simple change to Resource Manager code to
> introduce a plugin that can redefine or extend Rmgrs.

It looks very reasonable to me.

> * values 33-127 are available by centrally managed registration to help
> avoid conflicts in Postgres projects on pgfoundry
> * values 128+ are user defined

One thing to worry about is a confliction of RmgrId. We can check
conflictions in redo because rmgrs are actually registered, but
we might need to check conflictions even in a normal running.
Extensions that write own XLog record can use arbitrary RmgrIds without
restrictions. It would be safe if we check whether RmgrIds required by
extensions are actually unused.

For more safe, we could store signatures of extensions in control file.
We store mapping of RmgrId to signatures in it and checks no changes since
last shutdown. UUID types (128 bits) would be good for the signature.

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center

ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> writes:
> Simon Riggs <simon(at)2ndQuadrant(dot)com> wrote:
>> * values 33-127 are available by centrally managed registration to help
>> avoid conflicts in Postgres projects on pgfoundry
>> * values 128+ are user defined

> One thing to worry about is a confliction of RmgrId.

I think Simon's proposal was sufficient for that already. It seems
fairly comparable to the longstanding situation for statistics "kind"
numbers in pg_statistic, and we have had hardly any requests for new
allocations of those; conflicts in the field are simply nonexistent.

If we ever get to the point where there are groups of hackers competing
for the right to use rmgr IDs, I figure all the current members of
pgsql-hackers will have retired rich ;-)

regards, tom lane

On Wed, 2008-08-20 at 10:46 +0900, ITAGAKI Takahiro wrote:

> One thing to worry about is a confliction of RmgrId. We can check
> conflictions in redo because rmgrs are actually registered, but
> we might need to check conflictions even in a normal running.
> Extensions that write own XLog record can use arbitrary RmgrIds
> without restrictions.

That sounds quite hard. I'm putting in a check on the id itself, which
will be more than we had before...

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support