Horton

Re: Extensible Rmgr for Table AMs

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: Jeff Davis <pgsql@j-davis.com>
Cc: Julien Rouhaud <rjuju123@gmail.com>, Robert Haas <robertmhaas@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Amit Kapila <amit.kapila16@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Simon Riggs <simon@2ndquadrant.com>
Date: 2022-04-04T04:33:37Z
Lists: pgsql-hackers 
Hi,

On 2022-03-31 14:20:51 -0700, Jeff Davis wrote:
> If you are still concerned, I can switch back to separate tables to
> eliminate the indirection for built-in rmgrs. Separate rmgr tables
> still require a branch (to decide which table to access), but it should
> be a highly predictable one.

I still think the easiest and fastest would be to just make RmgrTable longer,
and not const. When registering, copy the caller provided struct into the
respective RmgrData element.  Yes, we'd waste a bit of space at the end of the
array, but it's typically not going to be touched and thus not be backed by
"actual" memory.

Greetings,

Andres Freund

Commits

  1. Fix off-by-one error in pg_waldump, introduced in 5c279a6d350.

  2. Fix another buildfarm issue from commit 5c279a6d350.

  3. Fix warning introduced in 5c279a6d350.

  4. Custom WAL Resource Managers.

  5. Make logical decoding a part of the rmgr.